Faq/Calc/Accuracy/da

Iboende problem med nøjagtighed
Calc benytter, ligesom den meste anden software til regneark, den kapacitet til regning med flydende komma, der findes i hardwaren. Givet at den meste samtidige hardware bruger binær aritmetik med flydende komma med begrænset nøjagtighed, defineret i IEEE 754, kan mange decimaltal - herunder så enkelt som 0,1 - ikke repræsenteres i Calc (som internt bruger 64-bit-tal med dobbelt præcision). Beregninger med disse tal med nøjagtighed resulterer nødvendigvis i afrundingsfejl, og de vokser med hver enkelt beregning. Dette er ikke en fejl, men er forventet og aktuelt uundgåeligt uden anvendelse af komplekse beregninger i softwaren, som ville medføre urimelige indskrænkelser af ydelsen, og derfor urealistiske. Brugerne må tage højde for dette og benytte af afrunding og sammenligninger med epsilon om nødvendigt.

Et eksempel:

Dette vil give resultatet -999.129999999997 i A3, i stedet for det forventede -999.13 (du kan være nødt til at forøge celleformatets antal af viste decimaler for at se dette).

Due to the specific of time representation in Calc, this also applies to all calculations involving times. E.g., in the following example, the cells A1 and A2 show the date+time data as entered (in ISO 8601 format):

Cell A3 will show 00:09:59.999999 instead of expected 00:10:00.000000 if formatted using [HH]:MM:SS.000000 format string. This happens despite only whole numbers of hours and minutes were used, because internally, any time is a fraction of a day, 12:00 (noon) being represented as 0.5. The data in A1 is represented internally as 43934.5125, and in A2 as 43934.5055555555591126903891563 (which is not exact representation of the entered datetime, which would be 43934.505555555555555555...). Their subtraction results in 0.00694444443287037, a value slightly less than expected 0.00694444444444..., which is 10 minutes.