Re: [sv-users] bugg?

Okej, jag ser att jag råkade svara direkt till dig istället för till
gruppen… igen. Att jag aldrig lär mig… men detta ska väl gå till gruppen, i
alla fall.


Den ons 26 aug. 2026 kl 19:42 skrev Lars-Göran Hansson <lg@lgr.se>:

> För att testa enkelt
> A1=139859,9
> A2=123885,4
> B1=137288,1
> B2=126457,2
> C1= =A1-B1
> C2= =A2-B2
> D2= =C2+C1
> Här finns inte mer än 1 decimal i någon cell, men D2 blir oläslig ändå.
Precis, och förklaringen är den jag nämnde tidigare.
Och D2 är ju inte oläslig, den utläses som -1,45519·10⁻¹¹. ”E” betyder ju
bara ”exponent”, och är ett vedertaget sätt att skriva mycket höga tal
(”E+”) och även tal mycket nära 0 (”E-” som i detta fallet), det vill säga
mycket små tal. Det blir ju väldigt oöverskådligt att skriva
0,0000000000145519, som (om jag inte råkade räkna fel på decimalerna) är
exakt samma sak.

Du använder som sagt bara en decimal i vårt decimala talsystem, men datorer
kan inte räkna med decimala tal, bara med binära och sedan omvandla fram
och tillbaka, och det är vid omvandlingarna du får dessa avvikelser.
Tag som sagt exemplet 0,1 igen, datorn omvandlar det först till binärt, men
den binära versionen av 0,1, som decimalt ser så väldigt jämnt och fint ut
för oss, blir ett tal med oändligt många bitar, för att vi ska få exakt
0,1:
0,00011001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100110011
och så vidare i all oändlighet. Men vi har inte oändligt med bitar, och då
får vi inte heller exakt rätt resultat.
Så, bara för att visa principen:
Säg att vi har 8 bitar till vårt förfogande till decimalerna till höger om
decimalsymbolen. 0,1 decimalt blir då 0,00011001 binärt. 0,2 blir
0,00110011.
Ta nu 0,2-0,1 binärt. Decimalt är det ju enkelt: 0,2-*0,1*=*0,1*, så vi
borde ju få exakt samma svar som det vi subtraherade, eller hur?
0,00110011
-0,00011001
–––––––––––
0,00011010

Såg du var som hände? Vi fick nu 0,00011010, inte 0,00011001! Så vilken av
dessa är exakt 0,1? Ingen:
0,0001001=0,09765625
0,0001011=0,10546875

Nu jobbar ju datorn med betydligt fler än 8 bitar, vilket också förklarar
varför dina svar skiljer sig från verkligheten först i elfte decimalen,
medan det skiljer sig i tredje decimalen i mitt mer grovhuggna exempel. En
decimal motsvarar drygt 3 bitar i noggrannhet, exakt blir det
log(10)/log(2)≈3,322…, så om du vill ha minst 10 decimalers noggrannhet
behöver du alltså minst 34 bitar.

Detta är orsaken till att du får de resultat du får! Du tycker att du bara
har en decimal, datorn tycker att det är lite mer komplicerat än så.


Sedan kanske man kan tycka att LibreOffice Calc ska kompensera för detta på
något sätt, men jag är inte säker på att det skulle fungera i alla lägen.
Bara av ren nyfikenhet, har någon testat detta i Excel eller andra
kalkylprogram? Blir resultatet samma eller har de löst detta på något sätt?


Vänliga hälsningar

Johnny Rosenberg



> Mvh
> Lars-Göran Hansson
>
> Den 2026-08-26 kl. 19:14, skrev Johnny Rosenberg:
>
> Det går inte att bifoga filer till denna grupp, men vad jag kan se på din
> beskrivning av problemet är det inget fel, utan bara en effekt av hur
> datorer och binära tal fungerar. -1,4552E-11 är ju -1,4552·10⁻¹¹ och det i
> sin tur är ju -0,000000000014552, det vill säga i princip 0. Det är en
> rest, helt enkelt, som beror på avrundningsfel ”under huven” när man
> konverterar till och från binära tal (de berömda ettorna och nollorna).
> Exempel: 0,1 blir binärt 0,00011001100110011…, där siffrorna 0011 upprepar
> sig i all oändlighet. Har du färre än oändligt många binära siffror, så
> blir det inte exakt 0,1, men ju fler siffror, eller ”bitar” som man brukar
> kalla dem, desto närmare kommer man. Det visade antalet ettor och nollor
> jag nyss gav för 0,1 blir i själva verket 0,09999847412109375, så det är
> ju väldigt nära 0,1 som sagt, men inte exakt.
>
> En lösning är ju att avrunda svaret till färre än 11 decimaler redan i
> formeln, för att säkerställa att små avrundningsfel ”slukas upp”.
> Exempelvis kan du kanske nöja dig med en precision på säg 8 decimaler, och
> istället för ”=A9-B9” kan du då skriva ”=AVRUNDA(A9-B9;8)”.
> Man kan också formatera bort decimalerna, men nackdelen med det är att det
> då visserligen ser ut som 0 i cellen, men om du sedan exempelvis ska
> formatera cellen villkorligt så att den får ett visst format om den är 0,
> så blir den ju inte i det formatet om det riktiga värdet inte är riktigt 0
> även om det står 0 i cellen. Eller likadant om en annan cell ska få ett
> särskilt värde om din cell är 0: =OM(C9=0;"Äntligen blev cellen 0!";"Cellen
> är inte 0"), då kommer den att visa ”Cellen är inte 0” fast du med dina
> egna ögon kan se att den visar 0.
>
> Det finns också en inställning man kan göra så att cellens faktiska värde
> blir det som visas i cellen, men det har andra nackdelar i sin tur,
> speciellt om man senare glömmer bort att man har valt den inställningen.
>
>
> Vänliga hälsningar
>
> Johnny Rosenberg
>
>
>
> > Ruta D10 borde bli 0
> > och det blir den om jag skriver in 2571,80 manuellt i C9 men då C9 är
> > A9-B9 (vilket också blir 2571,80) får Libre office calc inte till det utan
> > det blir -1,4552E-11 i stället.
> > Vad kan det vara för fel?
> >
> > Mvh
> > Lars-Göran Hansson
> > --
> >
> > --
> > For unsubscribe instructions e-mail to:
> > users+unsubscribe@sv.libreoffice.org
> > Problems?
> > https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> > Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
> > List archive: https://listarchives.libreoffice.org/sv/users/
> > Privacy Policy: https://www.documentfoundation.org/privacy

-- 
For unsubscribe instructions e-mail to: users+unsubscribe@sv.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/sv/users/
Privacy Policy: https://www.documentfoundation.org/privacy