Regneark blev deres skæbne

Som tommelfingerregel har normal programkode en fejl per 1000 linier kode.

Men forestil dig at programmere hvis du kun kan se en linie ad gangen?

Der er noget, regneark, der tyder på at det øger fejlraten med en faktor 10, til 1%.

Et eksempel er de betonbobbledæk til DR's byggeri der blev fejldimensioneret på grund af fejl i et regneark.

Det passer meget godt med min egen erfaring, jeg har brugt regneark siden 1985, hvis der ikke var andre muligheder og jeg stoler per definition ikke på dem, før jeg har kigget og checket alle celler igennem.

Det primære med regneark at de får ting til at se alt for nemme ud, simpelthen ved at vise det komplexe lag hvor formler og makroer lever og hvor fejlene befinder sig.

Men problemet rækker videre end det.

Hvis man f.eks taster "march3" i et felt, finder Excel selv ud af at det nok er en dato, problemet er bare at det nogen gange navnet på en genetisk DNA sekvens.

Jeg begynder at have en mistanke om, at fremtidige arkæologer ikke vil udpege hverken atombomber eller klimaforandringer som årsag til denne civilizations forfald, men i stedet udpege regnearket som synderen.

phk

Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Martin Zacho

..i LibreOffice 5.1.4.2 at taste følgende i en celle (uden ""):
"+1.4/E10"
Her ville jeg normal mene at jeg ville opnår resultatet af 1.4 delt med værdien af celle "E10", da 0"+" normalt er short hand for "=", men nej - resultatet bliver i mit tilfælde 1.40E+10, hvor E10 har værdien "2".
Hvis jeg laver samme nummer med andre celler end "E?", så får jeg det forventede resultat.

Første gang jeg har oplevet det - har lige opdateret min Ubuntu fra 12.04 til 16.04.

Hans Schou

Hvis alle celler kun består af regneudtryk med maksimum to variable, så alle mellemregninger er synlige, så er der en lidt større chance for at man selv eller en anden ser fejlen.

Lidt ligesom regnelæreren i skolen, der altid ville se mellemregninger. (og så kunne man også redde sig et sekstal, selv om det var forkert. (gælder ikke for bobbledæk))

Eskild Nielsen
Martin Bøgelund

Jeg begynder at have en mistanke om, at fremtidige arkæologer ikke vil udpege hverken atombomber eller klimaforandringer som årsag til denne civilizations forfald, men i stedet udpege regnearket som synderen.

Det behøver man ikke fremtidige arkæologer til.

Enhver nutidig datalog, eller andre med tilsvarende indsigt, vil straks se at den sammenpladring af data, forretningslogik og præsentationsformat, som udføres i en enkelt celle, sammen med den uoverskuelulighed der opstår når man kun kan fokusere på enkeltceller, er det samme som at købe en VIP-billet til Fejlenes Festival.

Carsten Poulsen

Problemet begrænser sig ikke til regneark, men alle steder, hvor der tilføjes hjælpefunktioner, som forsøger at gætte sig til, hvad det er du er i gang med!!
Prøv bare at slå stavekontrollen til på en smartphone og skriv noget teknisk, som kan være dansk blandet med fagudtryk - jeg har opgivet stavekontrollen, fordi den er for diktatorisk; den kan ikke finde ud af, at når edit distance er stor, så skal den bare holde snitterne for sig selv. I sidste ende er det mig, som skriver og bestemmer, hvad der skal stå - også nåt jeg tager fejl!!

Min egen holdning til regneark er i øvrigt, at de er fine til ukritiske beregninger og undersøgelser, hvor resultatet skal vurderes bagefter.
Så snart der er tale om kritisk databehandling, er reviwegnede systemer at foretrække - typisk i form af sekventielle programmer, som kan gennemgås og testes især regressionstestes med et relevant datasæt. Problemet med regneark er, at automatisk testning kan gennemføres, men er langt mere besværlig end sekventielle programmer. Konfigurations- og versionsstyring er desuden næsten umuligt.

I almindelighed bruges regneark til alt muligt og umuligt, hvor enten egentlige databaser eller specialiserede applikationer havde været et langt bedre valg.

Torben Mogensen Blogger

En anden fejlkilde er, at celleadresser ændres, når man kopierer en formel. Det kan være praktisk, når man vil summe indholdet af fem søjler, at regnearket selv retter søjlenummeret, når man kopierer formlen fra søjle 1 til søjle 2, osv, men i andre tilfælde er det bare irriterende. F.eks. hvis man vil have både sum og produkt af række 1 til 100, så kopierer man formlen for sum til cellen nedenunder og retter sum til produkt. Men så har regnearket ændret formlen, så man får produktet af række 2 til 101.

Det burde i øvrigt ikke være svært at lave en knap, der skifter hele arket fra visning til redigering, så alle formler er synlige (og retbare, uden at det skal ske i toplinjen) samtidigt. Når man vil se resultatet, skifter man tilbage til visning. Navngivning af celler eller områder, så man ikke behøver at bruge cellenumre, kunne også være en ide.

Tom Paamand

Beregninger kan drille, men nogle øjne går åbenbart blinde blot på grund af de mange celler i et regneark. Jeg fandt en indlysende slåfejl på fem milliarder i et statsligt regneark, hvor fejlen gjorde værdien fem gange større end alle de sammenlignelige tal i samme område. Tallet var uden korrektur eller yderligere omtanke indberettet til EU, og indgår nu i diverse offentlige statistikker og beregninger.

Martin Bøgelund

En anden fejlkilde er, at celleadresser ændres, når man kopierer en formel. Det kan være praktisk, når man vil summe indholdet af fem søjler, at regnearket selv retter søjlenummeret, når man kopierer formlen fra søjle 1 til søjle 2, osv, men i andre tilfælde er det bare irriterende.

Her må man være fair og sige, at det kan man faktisk komme om ved, ved at skrive sine referencer som konstante angivelser, der ikke ændres ved kopiering, i modsætning til de variable angivelser, som "følger med" forskydningen i en kopiering.

$-tegnet er din ven :-)

Peter Holm Jensen

Regneark er smarte når man skal lave lidt simpel regning og vise en masse tal/måske kurver, men hvor har jeg mange gange set alle mulige "work around" for at løse et problem. Ofte er det meget nemmere at flikke et python eller scilab script sammen, men det er vist ikke en disciplin på DJØF skolen......

Carsten Hansen

Siden Visicalc har programmørerne været efter regneark.

Her er et eksempel på programmørkritik:
https://stenci.la/stencila/blog/introducing-sheets/spreadsheets-are-dead...-

Mere strukturerede alternativer som f.eks. IFPS kunne desværre ikke klare sig i konkurrencen.

https://en.wikipedia.org/wiki/Spreadsheet#Programming_issues
Spreadsheets are a popular End-user development tool. EUD denotes activities or techniques in which people who are not professional developers create automated behavior and complex data objects without significant knowledge of a programming language

NB:
Jeg har lært, at 20.E og 20E er dårlige afdelingskoder.

Torben Mogensen Blogger

Et af problemerne er, at regneark bruges til ting, som det aldrig var meningen, de skulle bruges til: Statslige finansielle modeller, naturvidenskabelige simuleringer, osv. Regneark var udviklet for at gøre simple regnskaber enklere, og så længe man holder sig til for eksempel regnskaber for mindre foreninger, medlemslister for ditto, osv, så er det et fint værktøj. Men regneark mangler struktur og sanity checks, og er derfor uegnede til mere komplicerede eller omfattende beregninger.

Erik Trolle

Jeg lavede netværk i et entreprenørfirma som har lavet meget som planlagde mange store jordflytning arbejder og kloak i DK og det Nordlige Tyskland, det var motorvej og viadukter og broer, det hele var lavet i DOS Quartro Pro. Som blev brugt som front end til CAD systemer.

Ingeniøren havde prøvet mange regneark af og kun Quartro Pro var nøjagtig nok til det arbejde han lavede. Det mest brugte MS-Excel, var alt for unøjagtig til hans brug.

Alle i Danmark vil på et eller andet tidspunkt over storebælt og andre motorveje som er beregnet i Quardro Pro.

Per Krarup

Det burde i øvrigt ikke være svært at lave en knap, der skifter hele arket fra visning til redigering, så alle formler er synlige (og retbare, uden at det skal ske i toplinjen) samtidigt.

Den efterlyste knap findes. I Excel er det - Formulas -> Show Formulas (i Formula Auditing sektionen).

Jeg redigerer aldrig i toplinjen. Bruger altid F2. Dobbeltklik virker på samme måde.

Torben Jensen

Jeg bruger regneark dagligt, og er også ret tit træt af editoren til formler. Linien i toppen synes jeg trods alt er bedre end at redigere i cellen, da cellen tit har problemer med at afslutte redigering bare man klikker forkert ét sted, og mht skærmbredde.

Men jeg har tit undret mig over : hvorfor har MS ikke, i en eneste version siden Excel for Win95, lavet en lækker formeleditor med autocomplete, pæn indrykning, markering af parantesniveau etc etc ? Der findes den slags til HTML, til tekst, javascript, og ethvert programmeringssprog. Men ikke Excel.

Nå ja, og så det forbandede i at sidde på en polsk kundes PC, hjælpe med Excel, og prøve at huske hvad =if(...) nu hedder på polsk. Eller bare på dansk. Hvorfor man ikke kan slå formelnavne over til engelsk er mig også en gåde.

I øvrigt: indenfor den tekniske industri hvor jeg arbejder (produktion, trykkeri mv) er Excelformatet en de facto databasestandard, og næsten lige så sikker som CSV :)

Anne-Marie Krogsbøll
Tom Paamand

Jeg fandt en indlysende slåfejl på fem milliarder i et statsligt regneark, hvor fejlen gjorde værdien fem gange større end alle de sammenlignelige tal i samme område. Tallet var uden korrektur eller yderligere omtanke indberettet til EU, og indgår nu i diverse offentlige statistikker og beregninger.

Fortæl, fortæl!
(Og er du sikker på, at det er en slåfejl, og ikke tilsigtet?)

Først måtte jeg snakke med en venlig embedsmand en del gange, der ville høre om der virkelig var gode grunde til at kikke nærmere på disse tal. Det holdt jeg stædigt fast i - og de har både skrevet tak nu, og udsendt en revideret udgave. Men det ændrer ikke på de farvelagte statistikker rundt om i EU og Omegn, hvor Danmark fortsat står placeret i den forkerte ende af diverse skalaer - og hvad der ellers måtte være af følgevirkninger. Hvad det helt konkret drejede sig om, vil dukke op i medierne, når jeg har gravet færdig!

Anne-Marie Krogsbøll

Tak for svar, Tom Paamand, og hold da op, hvor det lyder spændende.
Men "slåfejl"? Kunne der være tale om talfifleri i stedet - med bekvemme politiske "følgevirkninger" (a la landbrugspakken)? Posterne ovenfor illustrerer jo, hvor svært det kan være at afsløre den slags. Godt at du var vågen her, jeg er spændt på at høre, hvad det handler om.

Thomas Peter Berntsen

En kunde, som vi engang udviklede et forretningssystem for, havde en central, knopskudt finansiel beregningsmodel relateret til deres domæne, der var implementeret i en Excel-workbook (flere regneark), og som skulle danne grundlag for en beregningsmotor i dette nye forretningssystem.

Vi så risikoen i kludetæppet og holdt stædigt fast i, at vi ønskede at analysere og dokumentere den eksisterende model med matematisk notation (LaTeX), for siden at ville at gennemgå alle detaljer af modellen (datakilder, formler etc.) med kunden, førend vi på nogen måde kunne stå på mål for validiteten af den kommende beregningsmotor og de ricisi, det ville indebære for kunden.

Dette var ikke helt nemt at få igennem ledelseslaget, idet det betød en budgetforøgelse, og det var heller ikke nemt at sælge selvsamme idéen om, at beregningsmotoren skulle have fuld code/test coverage, hvormed den kunne, og ville, blive programmatisk testet med forskelligartet parametrisering - og kræve kundens sign-off - i forbindelse med hver release.

Det var lidt af en kamp, der dog, ifølge dem selv, endte med at give dem en betydelig ekstraindtægt i årene der kom, idet de fik rettet kritiske fejl i deres hidtidige, regnearksbaserede model. Systemet tjente sig selv ind på et års tid alene pga. dette arbejde med beregningsmodellen.

Så hvad kan man lære af det? Well, regneark er et fantastisk redskab for brede brugerskarer til (ret funktionel) programmering af diverse beregningsmodeller, men kompleksiteten i modellerne er så godt gemt - og brugerne så lidt trænede i at teste og verificere beregningsmodellerne programmatisk - at det ofte kan lede til fejl blot at have modellerne repræsenteret i regneark uden yderligere kvalitetssikring.

Bent Jensen

Det man selv vil kunne lave og beregne på et stykke papir. Hvis man have tid og tålmodighed nok. Selvom der nok vil være flere fejl i det manuelt beregnet.

Mit forsøg på at fortælle en point, man skal selv kunne gennemskue og forstå hvad der sker i et regneark, hvis ikke man kan det så skal man ikke bruge det.

Hvorfor er mathcad ikke nævnt som alternativ til ingeniører ?
Vi afleveret da reporter og andet skriven og dokumenteret i det. Men det have en lidt stejl indlæringskurve, og jeg bandet det i starten langt væk.

Log ind eller Opret konto for at kommentere