Discernământ matematic în informatică

https://www.mixcloud.com/RadioRomaniaCultural/erezii-moderme-discern%C4%83m%C3%A2nt-matematic-%C3%AEn-informatic%C4%83-22-martie-2020/

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