Eugenia – epilog de etapă. Noile cutii ale Pandorei
17 January 2020
Maeștrii constructori ai antichității (II) Ansamblul Brihadisvara din Tajore, India
20 March 2020

Discernământ matematic în informatică

Informatica este un univers discret și finit: Univers poate fi considerat un termen forțat față de accepțiunea uzuală: informatica este, cu toată extensia și sofisticarea, o producție umană, în evoluție explozivă, dar fără legi ale naturii (ne)descoperite. Artificialitatea universului informatic – caracterizare la rându-i, disputabilă – ar induce ideea că suntem în control asupra oricăror producții… mici demiurgi auto-supra-evaluați.

De la filozofare la realitate: în iunie 1996, racheta Ariane V a explodat la scurt timp după lansare, datorită – cum avea să se constate nu fără consternare – unei erori propagate, de rotunjire a calculelor necesare dirijării propulsiei și, în definitiv, a rachetei. Situația merită explicată: un parametru (numit BH – Horizontal Bias) era gândit să fie reprezentat într-un format de 64 de biți cu virgulă mobilă (floating) și, la un anumit stadiu de calcul, să fie rotunjit într-un număr întreg, pe 16 biți, de transmis servomecanismelor. Însă, între alte scăpări, au fost menținute unele softuri care funcționaseră fără probleme la Ariane 4. Dar, Ariane 5 a avut alt plan al decolării, ceea ce a condus rapid la numere foarte mari în floating 64, imposibil de reprezentat și rotunjit într-al doilea format, pe numai 16 biți. Când operația a devenit imposibilă, s-a produs autodirijarea catastrofală și distrugerea imediată a navei.

Există, însă, fenomene de calcul informatic specifice formatelor de reprezentare în virgulă mobilă – de altfel, utilizate frecvent datorită altor calități – care nu sunt bănuite în accepțiune comună. Ca exemplu, procesarea repetată poate conduce la rezultate greșite, aberante chiar. Prin repetată se înțelege de milioane și miloane de ori – situație obișnuită în lucrul cu algoritmi și caracteristică forte a computerului.

Într-o accepțiune obișnuită, calculele, chiar masive, pe hârtie sunt, întotdeauna clare iar numerele, funcțiile – precise. Dar, multiplicate în milioane de instanțe pe secundă și obligate la renunțarea la continuitatea analogică, în plus – constrânse la reprezentări într-un registru finit, aceleași numere știute „cuminți” o pot lua ușor razna. Într-un sens mai larg, repetabilitatea și viteza de calcul, elemente-cheie ale avantajului mașinii asupra minții umane, pot conduce la rezultate catastrofale.

Detectarea erorilor de concepție în dezastrul Ariane 5 s-a produs relativ rapid. Cu toate că problemele descoperite erau – să le numim – triviale, întrebarea „cum a fost posibil să se greșească astfel?” nu are un răspuns simplu.

Un avertisment timpuriu este conținut în interviul acordat în anul 2000 televiziunii publice olandeze VPRO de unul dintre părinții fondatori ai programării algoritmice – profesorul olandez Edsger Dijkstra (1930 – 2002), laureat, în 1972, al premiului Turing, echivalentul Nobel în informatică. Pentru cititorii și radioascultătorii sensibili la abordări de referință ale gândirii în domeniu (și nu numai), interviul poate fi urmărit la https://www.youtube.com/watch?v=RCCigccBzIU. În sensul acestui articol, câteva citate sunt relevante:

”S-a întâmplat în 1969, chiar după prima aselenizare. Eram la Roma, la o conferință NATO pe teme de inginerie software, unde l-am întâlnit pe Joel Aron, fostul șef al Federal Systems Division la IBM, care fusese răspunzător pentru software-ul Apollo de dirijare a zborului. Știam că fiecare misiune Apollo solicita circa 40.000 de linii de cod, ceea ce este foarte mult. Am fost profund  impresionat că au reușit să le scrie corect; când l-am întâlnit pe Joel Aron, am spus: cum faceți asta ? Facem ce? a întrebat el. Să scrieți corect întreg acel software. Corect? – răspunde. Și spune că, într-una din  secvențele de calcul ale orbitei modulului lunar, Luna fusese reprezentată că respingând, în loc să atragă… Au descoperit eroarea accidental (! – sn.red.) Imaginați-vă: accidental. Cu cinci zile înaintea lansării. M-am albit și am spus: Băieții aceia au fost norocoși. Da, a fost de acord Joel Aron.

Cu acest flashback, să observăm că erorile catastrofale de programare se pot produce chiar și în cadrul proiectelor critice, precum programele spațiale, populate – nu mai este nevoie de subliniat – de minți și conștiințe de vârf. A greși este omenesc – s-ar putea contraargumenta. Și totuși…

Să fie, oare, posibil, ca însăși insuflarea, educarea modului de lucru în programare să fie la originea unor erori, indiferent cât de competent și „de încredere” a devenit programatorul? Sa fie, oare, chiar și pentru un specialist, probabilitatea erorii de programare independentă de cunoștințe și experiență, dar legată de educația timpurie în domeniu? Condamnat, adică, la a greși mai des, orice ar face prentru a evita aceasta?

Ideea pare o veritabilă erezie modernă. Ar putea să prevaleze o altă formare a gândirii asupra paradigmei perene iterative programare-depanare? Profesorul Edsger Dijkstra remarca, în interviul din 2000, rădăcinile adânci ale modului de lucru actual: ”…metoda iterativă a programării este un obicei foarte anglo-saxon. Educația britanică este copleșită de acesta. Oamenii învață că, atunci când scriu un program, nu este nevoie să-l facă bine de prima dată… scrie doar ce-ți vine în minte și corectează apoi, iar și iar, până obții produsul dorit….Dacă în fizică este ceva ce nu înțelegi, te poți mereu ascunde după necunoscutele profunzimi ale naturii. Poți, mereu, da vina pe Dumnezeu – nu ai făcut-o atât de complexă tu însuți! Dar, dacă programul tău nu merge, nu te poți ascunde în spatele cuiva! Nu te poți ascunde în spatele unei naturi obstinate; un zero este un zero, un unu este un unu! Dacă nu merge, tu ai încurcat lucrurile.”

Dacă ideea probabilității mari și obiective a greșelii în munca informaticianului clasic ar fi acceptabilă, atunci ar apărea, de asemenea acceptabile, răspunsuri la întrebarea „ce e de făcut?”

Între acestea, cel mai eretic a fost deja dat: lucrul în mentalitatea scrierii cât mai apropiate de perfecțiune, încă de la  prima versiune a programului. Această strategie este refuzată în cele mai productive (bănoase) ramuri, datorită „minei de aur” reprezentate de actualizări (update-uri).

Cum s-ar putea ridica ștacheta calității programării informatice chiar și azi, când experiența acumulată este uriașă? Un răspuns este ideea-titlu: discernământul matematic aplicat în informatică.

Nu este vorba, desigur, despre exemple precum calculul rezultatului unei operații sau al valorii unei funcții. Se pune, în primul rând, problema folosirii logicii matematice, purificate de numeroasele „reziduuri convenționale” (în loc de convenabile) aparent simplificatoare, dar potențial înșelătoare și distructive.

Exemplele, aici, nu sunt simple; acestea vizează considerabilul corpus al folosirii operatorilor logici și termenilor în programare. Și, sau, negație, adevărat, fals, se combină în nenumărate moduri în scrierea instrucțiunilor pentru procesor. În special sintagmele dacă-atunci și, mai ales, repetă pun logica umană la subtile încercări. Repetă  este un nebănuit generator de complexitate în programare, prin simpla determinare a intrării procesorului într-o buclă. Milioane de repetări ale unor secvențe, chiar de bază, se pot solda cu produse de calcul surprinzătoare…

Când complexitatea (folosirii) instrucțiunilor depășește capacitatea de urmărire  a programatorului, încep să intervină erori care se doresc eliminate prin clasica metodă iterativă deja menționată: rulare-poticnire-identificare(uneori dificilă)-depanare. După astfel de proceduri, repetate, de corecție, programele trebuie să fie declarate finalizate, gata de lucru. Problema este când rămân nedetectate erori  adânc ascunse, care pot să nu se manifeste niciodată, făcând să se creadă că piesa software găsită este perfectă. Aceasta va fi plasată în bagajul de experiență (secretă) și refolosită cu încredere, până când, într-un context, crachează.

Soluția discernământului indus de logica matematică în logica de programare implică un ingredient de „renunțare de sine” a programatorului (evident, cunoscător). Acesta consimte să „evadeze din inteligibil” și se „încreadă” în proceduri  matematice a căror rigurozitate le situează, dintru început, deasupra „bagajului de experiență”, intuiției ori bunului-simț (informatic, desigur!). Cititorii și radioascultătorii vor înțelege că exprimările plastice sunt folosite pentru elocvență, cu intenția surprinderii esenței demersului.

Un al doilea exemplu-cadru în susținerea discernământului matematic în informatică are legătură cu grupul raționamentelor aparent corecte care conduc la rezulatate paradoxale. Sofismele și paradoxurile matematice și logice abundă. Iată un exemplu-avertismentsimplu, dintr-un manual de referință (Calculus, Michael Spivak):

Fie x = y.  Se produce succesiunea: x2 = xy       x2 – y2 = xy – y2      (x + y)(x – y) = y(x -y) x + y = y   apoi, din ipoteză   2y = y   deci  2 = 1  …!

Lesne de înțeles – astfel de succesiuni (și altele, chiar complicate), utilizate fără suport matematic formal riguros, pot admite situații particulare care să genereze rezultate aberante.

La cealaltă extremă, pot fi considerate consecințe ale celor două teoreme ale incompletitudinii datorate lui Kurt Gödel (1906-1978) . Matemetician de geniu, a contribuit la fundațiile teoretice ale logicii folosite în informatică prin lucrările sale despre limbajele formale și, în cadrul acestora, despre limitele demonstrațiilor și calculului.  Apariția, din necunoaștere sau neglijență, în conceperea codului, a unei structuri logice imperfect demonstrate ar ruina aproape iremediabil programul, deoarece depanarea unei subtile erori conceptuale, nu sintactice, ar fi cvasiimposibilă. Compilatorul nu recunoaște decât erori de limbaj, iar comentariile „sigure” ale autorului de cod nu ar oferi, desigur, vreun indiciu.

Doar în treacăt merită menționată estimarea că 95% din programele numite „căutare binară” publicate până la sfârșitul anilor 1990 erau greșite, din motive logice. Prezentul oferă, aproape sigur, alte surprize.

În fine, un al treilea argument pentru atenția cuvenită matematicii aplicate în informatică poate fi rezumat într-un atribut: eleganță. O soluție elegantă înseamnă scurtă și corectă dintru început, prin contrast cu cea obținută în paradigma „scrieți, băieți, scrieți și depanați”. Am accentuat, desigur, extremele, dar realitatea rămâne una cantitativă, potențată și de creșterea puterii de calcul și stocare a calculatoarelor, care invită la „beția de cuvinte”. Considerente comerciale prevalează, desigur, și în această zonă: un program funcțional mai ieftin compus din 7000 de instrucțiuni  este preferat unei rezolvări în 4000, aceasta din urmă implicând eleganță – atribut calitativ și „scump”.

Desigur, nici o abordare nu garantează eliminarea completă a erorilor de programare. Dar, discernământul matematic în informatică ridică ștacheta calității rezolvărilor la niveluri intangibile sistemului bazat pe ciclul repetitiv asumat experiență-scriere-depanare.

Este de presupus că aplicațiile critice, de care depind vieți sau valori strategice, sunt concepute în perfecționism metodic, inclusiv -sau mai ales- matematic. Informațiile de gen din aceste zone sensibile sunt strict secrete. Dar, în afara acestei presupuse „cupole” a aplicațiilor și programatorilor, există perspectiva unei schimbări de paradigmă generală privind principiile matematice aplicabile în creația software?

Un posibil răspuns pozitiv ar putea fi generat de situațiile în care excedentul de putere de calcul și capacitate de stocare ar dispărea. Singurul grup care stresează în prezent posibilitățile sistemelor este detecția facială în timp real. Realizarea acesteia la scara unor grupuri masive de populație și unor geografii extinse implică resurse tehnice atât de mari încât eleganța (eficiență+acuratețe) rezolvărilor ar putea reintra, de nevoie, în cerințele proiectelor. S-ar putea, atunci, repune în drepturi zicerea profesorului Edsger Dijkstra: Testarea unui program poate arăta prezența unui defect (bug), dar este iremediabil neadecvat pentru certificarea absenței acestuia. Avangardă sacrificată, semințe ale unei posibile noi conștiențe.

redactor Florin VASILIU

Leave a Reply

Your email address will not be published. Required fields are marked *