LibreOffice Berekeningsnauwkeurigheid

Inherent nauwkeurigheidsprobleem

LibreOffice Calc gebruikt, net als de meeste andere werkbladsoftware, drijvende-komma wiskundige mogelijkheden die beschikbaar zijn op hardware. Aangezien de meeste hedendaagse hardware binaire drijvende-kommaberekeningen gebruikt met beperkte precisie gedefinieerd in de IEEE 754-standaard, zijn veel decimale getallen - zoals zo eenvoudig als 0,1 - kunnen niet precies worden weergegeven in LibreOffice Calc (die intern 64-bits dubbele-precisiegetallen gebruikt).

Berekeningen met die getallen leiden noodzakelijkerwijs tot afrondingsfouten, en die worden bij elke berekening groter.

Dit is geen bug, maar is te verwachten en is momenteel onvermijdelijk zonder gebruik te maken van complexe berekeningen in software, wat tot ongepaste prestatiestraffen zou leiden, en is dus uitgesloten. Gebruikers moeten daar rekening mee houden en afrondingen en vergelijkingen met machine epsilon (of eenheidsafronding) gebruiken als nodig.

Een voorbeeld met cijfers:

A

1

31000.99

2

32000.12

3

=A1-A2


Dit resulteert in -999,129999999997 in A3, in plaats van de verwachte -999,13 (mogelijk moet u de weergegeven decimalen in celopmaak verhogen om dit te zien).

Een voorbeeld met datums en tijden:

Vanwege de specifieke tijdweergave in Calc, geldt dit ook voor alle berekeningen met tijden. De cellen A1 en A2 hieronder tonen bijvoorbeeld de datum- en tijdgegevens zoals ingevoerd (in ISO 8601-indeling):

A

1

2020-04-13 12:18:00

2

2020-04-13 12:08:00

3

=A1-A2


Cel A3 toont 00:10:00 als de standaardopmaak [HH]:MM:SS op de cel wordt toegepast. In cel A3 wordt echter 00:09:59.999999 weergegeven in plaats van de verwachte 00:10:00.000000 als deze is geformatteerd met de opmaakreeks [HH]:MM:SS.000000. Dit gebeurt ondanks dat alleen hele aantallen uren en minuten werden gebruikt, omdat intern elk moment een fractie van een dag is, waarbij 12:00 ('s middags) wordt weergegeven als 0,5.

De gegevens in A1 worden intern weergegeven als 43934.5125, en in A2 als 43934.50555555591126903891563 (wat geen exacte weergave is van de ingevoerde datumtijd, die 43934.505555555555555555 zou zijn...).

Hun aftrekking resulteert in 0,00694444443287037, een waarde die iets lager is dan verwacht 0,00694444444444..., wat 10 minuten is.

Help ons, alstublieft!