Time-problemer rammer alle regneark

Også OpenOffice Calc vil regne forkert, når man ganger frem og tilbage med minutter.

Det er ikke kun Microsofts Excel regneark, der har problemer med at regne frem og tilbage med minutter, som det tidligere er beskrevet her på Version2.

Administrerende direktør i Ementor, Niels Henrik Sodemann, har netop sendt Version2 et skærmdump fra OpenOffice Calc, der viser præcist samme billede som det tidligere modtagne fra Lars Pehrsson i Dansk Sygeplejeråd.

Ifølge Ementor-direktøren er der ikke tale om en fejl i hverken Excel eller OpenOffice Calc, men mere et spørgsmål om, at mange ganger forskellige datatyper med hinanden.

»Der vil formentlig være tale om den samme regnefejl i alle typer af regneark, men det skyldes, at man i regnearkets matematikmotor ikke har en uendelig præcision, men der er en afrunding ved vist nok 15 decimaler, og det man gør, er, at man formaterer sine celler, så det giver mening i forhold til resultatet,« siger han.

Også Microsofts danske Office-ansvarlige Thomas Schnegelsberg har gjort Version2 opmærksom på problemet med afrunding af uendelige decimaler og henviser desuden til Wikipedia, der har beskrevet fænomenet.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thomas Hansen

Kan vi andre se.. Evt. få nogen kopier af de regneark?

For jeg har lige prøvet at efterligne billedet på OpenOffice (2.2 på Ubuntu) og Excel 97, og jeg får 60 over hele linjen i begge tilfælde.

  • 0
  • 0
Dennis Schwartz-Knap

ja det er rigtigt du får 60 når du gør det, men jeg kan genskabe akurat samme problem med excel 2003. Det eneste det kræver er at du afrunder med 10 eller flere decimaler. men hvem dælan vil have sine minut antal med 60,000000000000000s nøjagtighed. Altså jeg kan godt nøjes med bare 3 decimaler.

  • 0
  • 0
Thomas Hansen

@Dennis Schwartz-Knap

Jeg kan godt godtage at problemet ligger i floating points begrænsninger og formattering af celler. Det der undrer mig er at jeg ikke kan reproducere det i OO, selv med over 90 decimaler i formateringen. Med samme formattering viser 1/3 sig som kun værende precis til omkring de 15 decimaler.

Excel knækker ved 13 decimaler, så det burde OO jo også. Er der en magisk knap jeg har overset et sted? Eller håndterer Linux versionen floating point lidt anderledes?

  • 0
  • 0
Thomas Kjeldsen

Jeg undrer mig over hvem v2.dk's målgruppe er.

Er det for meget forlangt at målgruppen som en selvfølgelighed ved at maskiner er endelige og derfor er nødt til at introducere afrunding (og deraf følgende problemer) for at kunne repræsentere tal, der som bekendt, ikke er endelige?

  • 0
  • 0
John Laustsen

Problemet med floating point er vel helt generelt?
I al fald Google gør det også.

00.00.00 A2-A11440 B21000000000000000
00.10.00 10,00 10000000000000000
00.20.00 10,00 10000000000000000
00.30.00 10,00 10000000000000000
00.40.00 10,00 10000000000000000
00.50.00 10,00 10000000000000004
01.00.00 10,00 9999999999999994
01.10.00 10,00 10000000000000004
01.20.00 10,00 9999999999999994
01.30.00 10,00 10000000000000004

  • 0
  • 0
Thomas Hansen

@Thomas Kjeldsen
"Er det for meget forlangt at målgruppen som en selvfølgelighed ved at maskiner er endelige og derfor er nødt til at introducere afrunding (og deraf følgende problemer) for at kunne repræsentere tal, der som bekendt, ikke er endelige?"

Muligvis at version2s læsere burde vide bedre (tvivler jeg dog på, da målgruppen ikke er udviklere, men IT leder typer, har jeg ladet mig fortælle, som de fleste ved ikke nødvendigvis har megen teknisk indsigt), men vi snakker om et program som bruges af en hel del mennesker der ikke falder indenfor gruppen.

Hvad jeg undrer mig over er hvordan nogen i tidernes morgen kan have fundet det smart at basere regnearkenes tids fornemmelse på at et døgn = 1, når en hurtig 1.0/24 viser at selv en time ikke kan repræsenteres i en float.

Muligvis det ikke var Microsoft skyld, det stammer vel tilbage fra et af de spreadsheets som de har klonet, men hvorfor helvede er der ikke nogen der har ryddet op i det endnu?

  • 0
  • 0
Dennis Schwartz-Knap

Hmm jeg kan sgu heller ikke genskabe den på OO.. Men tilgængæld ligner at det er noget man har programmeret sig ud af, for den giver noget mærkelig ude i 13. decimal.

15:00:00, 16:00:00, 60,00000000000010000000
16:00:00, 17:00:00, 60,00000000000010000000
17:00:00, 18:00:00, 60,00000000000010000000
18:00:00, 19:00:00, 60,00000000000030000000
19:00:00, 20:00:00, 60,00000000000030000000
20:00:00, 21:00:00, 60,00000000000030000000
21:00:00, 22:00:00, 60,00000000000040000000
22:00:00, 23:00:00, 60,00000000000040000000

  • 0
  • 0
Jens Madsen

"Er det for meget forlangt at målgruppen som en selvfølgelighed ved at maskiner er endelige og derfor er nødt til at introducere afrunding (og deraf følgende problemer) for at kunne repræsentere tal, der som bekendt, ikke er endelige?"

Computeren har kun endelig regnenøjagtighed, fordi der bruges en coprocessor, med begrænset opløsning. Hvis computeren kodes uden coprocessor kan opnåes vilkårlig nøjagtighed, og det betyder at opløsningen til enhver tid kan øges, således at output altid svarer korrekt. Det er intet teknisk problem.

Problemet med regnefejl, og at computerne ikke udregner fejlen på dens output, er særdeles groft. Det kan nemt snyde, også i mange videnskabelige beregninger. Det burde være grundlæggende for alle programmeringssprog at de er uafhængige af den underlæggende hardware og coprocessorens nøjagtighed, og at de derfor altid opnår den nøjagtighed som er nødvendigt af hensyn til deres output. Problemet kan relativt simpelt løses, ved at flytte beregningerne over til at simuleres uden brug af coprocessor, hvis ikke coprocessorens nøjagtighed er nok. Men i fremtiden bør man nok overveje at gøre coprocessorene mere fleksible med hensyn til præcisision, således de kan konfigureres til en ønsket nøjagtighed, og at programmeringssprogene dermed kan bede om den nødvendige nøjagtighed, for at kunne angivne det antal decimaler som specificeres. Derved vil programmerne samtidigt regne ens, uafhængigt af hardware og processorens nøjagtighed.

Jeg mener klart, at det er en fejl. Men, desvære er det ikke kun en fejl i regneark, men en fejl i også programmeringssprogene, og i langt de fleste andre programmer. Årsagen til fejlen skal ikke søges i regnearket, men i programmeringssproget den kodes i.

  • 0
  • 0
Thomas Hansen

Oho..

Jeg får 60.0000000000001 når jeg når til 13:00-14:00, og den famøse 59.9999999999998 når vi runder 25:00-26:00... Og så skifter den ellers mellem de 2...

Så nogen har fikset de første 12 timer, og halvfikset de næste 12 igen..

Og hvis den dog bare havde regnet i sekunder i stedet, så havde problemet slet ikke været der.

  • 0
  • 0
Jesper Gaardbo Langhoff

Kolonne A og B er angivet som værende tidsfelter i formatet HH:MM:SS. Der vises værdier som 00:00:00, 01:00:00, 02:00:00 osv.

Kolonne C er formateret som et tal med 15 decimaler.

Med den nævnte formel bliver resultatet i alle tilfælde: 60.000000000000000

Jeg skal hjem og lave samme øvelse på min OO på Ubuntu.

  • 0
  • 0
Jørgen Henningsen

Nu er god software jo ikke kun et spørgsmål om hvem som koder bedste og mest fejlfrit. Det er jo ligeså meget et spørgsmål om hvem der hurtigst og bedst får skovlen under de fejl som der er. Der har et program som gnumeric i grunden en trackrecord som vist slår både OO-calc og Excel:

http://www.csdassn.org/software_reports/gnumeric.pdf

M.h.t. den her præsisions diskussion, så er grundreglen at en evt. unøjagtighed skal ligge på det sidste betydende chiffer, så tallet:

60,00000000000010000000

Det er ikke iorden, som representation for 60 ligeud. Hvis der derimod havde stået:

60,0000000000001 eller 59.9999999999998

Så havde det været fint nok. De efterstillede nuller er et udtryk for at man præsentere flere chifre end man har regnenøjagtighed til og det er gen. noget man ikke bør gøre, fordi de sidste chifre er fri fantasi.

  • 0
  • 0
Jesper Stein Sandal

Min indre fysiker vil påpege, at det alligevel ikke giver ret megen mening at arbejde med sekunder ud til 13.

I praksis vil man så i øvrigt løse sådanne afrundingsfejl ved at arbejde med heltal frem for decimaler, som er notorisk upålidelige i computere. I stedet for at regne i 0,0...001 sekunder vil man bruge milli-, mikro-, nano- eller picosekunder.

Udviklerne af regnearkene burde på den anden side have været klar over begrænsningerne og forhindret brugen af så mange decimaler, uden at brugeren skulle vælge at øge præcisionen.

  • 0
  • 0
Jens Madsen

"Udviklerne af regnearkene burde på den anden side have været klar over begrænsningerne og forhindret brugen af så mange decimaler, uden at brugeren skulle vælge at øge præcisionen."

Det bedste ville være, hvis programmet ikke kunne angive flere decimaler end muligt.

Eventuelt kan angives hvor mange decimaler der ønskes i resultatet (som print using i basic), og computeren kan baglands regne sig frem til den nødvendige præcisison for udregningerne.

Det vil udelukke fejl.

  • 0
  • 0
Jørgen Henningsen

Til Jesper:
I en dedikeret applikation har du ret. Der kan det ofte være en god ide at arbejde med heltal. Ligesom Java's antal millisekunder siden 1970. Det giver bare ikke rigtigt mening i et regneark, fordi regnearksprogrammet ikke kan vide hvilken betydning de enkelte felter har. Det er simpelthen kun brugeren, som kender præsisionen af de tal der indtastes. De fleste brugere af regneark forstår ikke den dybere mening i begreber som nøjagtighed og tolerance.
Til Jens:
Du har fuldstændigt ret. Regnearket bør ikke kunne vise flere chifre, end der er hold i. Det er god praksis. Jeg tror dog ikke på det vil udelukke fejl, fordi det som nævnt kun er brugeren som kender tallenes betydning. Regnearket regner bare med fuld præsision hele tiden og hvis brugeren stiller sin tabel forkert op, så kan betydningsfuld information sagtens forsvinde i regneunøjagtighed.

  • 0
  • 0
Torben Frandsen

@Thomas Hansen

"Hvad jeg undrer mig over er hvordan nogen i tidernes morgen kan have fundet det smart at basere regnearkenes tids fornemmelse på at et døgn = 1, når en hurtig 1.0/24 viser at selv en time ikke kan repræsenteres i en float."

Jeg skal gerne indrømme at min rutine i at regne i base2 er lettere rusten. Men kunne det samme argument ikke føres hvis man havde valgt at lade enheden være en time, et minut, et sekund eller et millisekund? Altså: Så vidt jeg lige kan regne, kan 1/60 eller 1/1000 heller ikke repræsenteres som en endelig brøk.

"Muligvis det ikke var Microsoft skyld, det stammer vel tilbage fra et af de spreadsheets som de har klonet, men hvorfor helvede er der ikke nogen der har ryddet op i det endnu?"

Jeg ved det ikke med sikkerhed, men man skulle være en dårlig it-mand hvis man ikke kunne slynge et par gæt ud, og påstå at de var kvalificerede:

1) En omskrivning ville brække bagudkompatibiliteten. Og den brækker man kun hvis man kan nøjes med under 10% af brugerne.

2) En omskrivning medfører risici for at genintroducere gamle bugs. Noget kunne tyde på, at MS har omskrevet noget præsentationskode og er blevet ramt af netop dette.

3 (bonusgæt)) En omskrivning koster tid og penge, som man vurderer er bedre brugt på udvikling af ny funktionalitet.

  • 0
  • 0
Thomas Hansen

@Torben Frandsen
"Jeg skal gerne indrømme at min rutine i at regne i base2 er lettere rusten. Men kunne det samme argument ikke føres hvis man havde valgt at lade enheden være en time, et minut, et sekund eller et millisekund? Altså: Så vidt jeg lige kan regne, kan 1/60 eller 1/1000 heller ikke repræsenteres som en endelig brøk."

Muligvis jeg ikke er vågen endnu, men jo, hvis du tager år, måneder, uger, dage, timer og minutter, men ikke hvis du tager sekunder.

Problemet med enhederne over sekunder er at de er baseret på 60 tals systemer, hvilket i den sidste ende betyder at vi har med problemet at repræsentere 1/3 at gøre for enheder som almindelige mennesker regner i hver dag. Hvis vi flyttede 1 til at være et minut i stedet, ville det fjerne problemet for de fleste der laver timeregnskaber i regneark, men det ville stadig være et problem for dem der ville have sekunds præcision.

Forskellen ved at vælge sekunder er at den næste mindre enhed ikke er et multiplum af 3 og derfor kan du f.eks. repræsentere 0.001 sekunder uden at det per automatik bryder rammerne for floating point. Selvfølgelig kan du stadig knække dem med en billion-billiard komma nul nul nul ... et, men sådan helt almindelige dagligdags beregninger er til at håndtere.

Og vi ville ikke have problemet hvis vi alle brugte Swatch Internet Time, da det netop er baseret på at et døgn er 1000 .beats, men det er en anden snak.

  • 0
  • 0
Peter Stricker

@Thomas Hansen
Du vi ikke undgå problemer ved blot at regne i sekunder.
Forestil dig at du har 10 forskelige opgaver, der tager henholdsvis 0.1, 0.2, 0.3,...1.0 sekunder og du har 1.0 sekund til at udføre dem og du vil gerne udføre så mange forskellige opgaver som muligt.
Du kan kun nå at udføre 3 opgaver for efter at have udført de opgaver der varer 0.1, 0.2 og 0.3 sekunder har du kun 0.39999999999999 sekunder tilbage til den sidste opgave.
Det er et problem med computeres repræsentation af reelle tal, som du ikke kan komme uden om.

  • 0
  • 0
Thomas Hansen

@Peter Stricker
OK, så hvis du har brug for at regne i tiende dele sekunder, bliver du nødt til at regne i den enhed istedet, men det demonstrerer jo netop problemet, bortset fra at i regneark kan du ikke få plads til 2.4 + 4.8 + 7.2 + 9.6 timer, hvis man følger dit eksempel..

Anyway, så var det ikke så meget et forsøg på at løse alle tids problemer en gang for alle, for så skulle vi udstyre Excel med uendelig præcision, meningen var at gøre den nogenlunde robust omkring det interval de fleste af os bruger til daglig.

  • 0
  • 0
Peter Stricker

@Thomas Hansen
Det var heller ikke min mening at pille dit forslag ned. Det vil selvfølgelig altid være bedre at vælge en tidsenhed hvor man kan regne i heltal som i dit eksempel, hvis det ellers er praktisk muligt.

Men der vil desværre også være tilfælde hvor absolut præcision ikke er muligt. Også "hverdags" eksempler:

En tænkt cykel har et hjul med en diameter på 1 meter, og kører med en hastighed af 1 omdrejning i sekundet. Hvor lang tid tager det for cyklen at tilbagelægge 1 meter?
Svaret kan ikke udtrykkes præcist med mindre man angiver det som en brøk, hvor pi indgår i nævneren.

Det vil være op til producenten af regnearket at gøre opmærksom på disse problemstillinger, men op til brugeren at finde holdbare måder at håndtere dem på.

  • 0
  • 0
Povl Ole Haarlev Olsen

"Computeren har kun endelig regnenøjagtighed, fordi der bruges en coprocessor, med begrænset opløsning. Hvis computeren kodes uden coprocessor kan opnåes vilkårlig nøjagtighed, og det betyder at opløsningen til enhver tid kan øges, således at output altid svarer korrekt. Det er intet teknisk problem."

Jeg synes nu stadig, der er et teknisk problem i at få uendelig mange bits ind på endelig plads.

Og så er det sådan set ligegyldigt om det er en coprocessor, processor eller mand med god lup, der skal kigge på de bits.

  • 0
  • 0
Log ind eller Opret konto for at kommentere