Värdesiffror i python

Det har att göra med att datorer räknar i bas 2. Om du ska uttrycka 1.1 (dvs. "1 och en tiondel") i bas 2, så får du en oändlig decimalföljd, ungefär som att "en tredjedel" har den oändliga decimalföljden 0.3333... i vårt vanliga talsystem. Och om vi bara hade 16 decimaler, så skulle vi ju få ett avrundningsfel när vi försöker uttrycka 1/3 med dom. Samma sak händer i datorn, fast med andra tal eftersom den räknar i en annan bas.

Skaft skrev:

Det har att göra med att datorer räknar i bas 2. Om du ska uttrycka 1.1 (dvs. "1 och en tiondel") i bas 2, så får du en oändlig decimalföljd, ungefär som att "en tredjedel" har den oändliga decimalföljden 0.3333... i vårt vanliga talsystem. Och om vi bara hade 16 decimaler, så skulle vi ju få ett avrundningsfel när vi försöker uttrycka 1/3 med dom. Samma sak händer i datorn, fast med andra tal eftersom den räknar i en annan bas.

Jag är med på att datorn räknar i bas 2, men mitt (antagligen felaktiga) argument är att 0.33 är 1/3 upp till 16 värdesiffror och därmed bör 1.1000...0 vara rätt och 2.1000...0 vara rätt upp till 16 värdesiffror, jag kan inte koppla hur det binära talsystemet ställer till det här? För det är ju antagligen någon sorts serie som konvergerar mot t.ex 1.1000...0, men den serien är ju korrekt upp till 16 värdesiffror?

Kan det vara så att jag har förstått begreppet värdesiffror fel i det här sammanhanget, om jag säger att jag vill skriva 1/3 upp till 3 värdesiffror, så tolkar jag det som att talet som skrivs ut är korrekt upp till tre värdesiffror alltså t.ex 0.333 är korrekt men inte 0.335

HaCurry skrev:

Kan det vara så att jag har förstått begreppet värdesiffror fel i det här sammanhanget, om jag säger att jag vill skriva 1/3 upp till 3 värdesiffror, så tolkar jag det som att talet som skrivs ut är korrekt upp till tre värdesiffror alltså t.ex 0.333 är korrekt men inte 0.335

Det stämmer.

Det som texten i början handlar om är att tal som har en exakt ändlig representation i bas 10 inte alltid har det i bas 2, så de blir avrundade redan genom att stoppas in i en programvariabel. Den viktigaste konsekvensen av det är att man inte ska jämföra flyttal med varandra, även om man tycker att de borde vara exakt lika, för de kan ha råkat ut för olika avrundningar på vägen. Men alla normala antal värdesiffror när man skriver ut tal är inget problem.

Experimentera gärna med Python.

Laguna skrev:

HaCurry skrev:

Kan det vara så att jag har förstått begreppet värdesiffror fel i det här sammanhanget, om jag säger att jag vill skriva 1/3 upp till 3 värdesiffror, så tolkar jag det som att talet som skrivs ut är korrekt upp till tre värdesiffror alltså t.ex 0.333 är korrekt men inte 0.335

Det stämmer.

Det som texten i början handlar om är att tal som har en exakt ändlig representation i bas 10 inte alltid har det i bas 2, så de blir avrundade redan genom att stoppas in i en programvariabel. Den viktigaste konsekvensen av det är att man inte ska jämföra flyttal med varandra, även om man tycker att de borde vara exakt lika, för de kan ha råkat ut för olika avrundningar på vägen. Men alla normala antal värdesiffror när man skriver ut tal är inget problem.

Experimentera gärna med Python.

Alright, så jag testade runt litegrann och ville kolla uppförandet av flyttal när man adderar dom. Jag visste sedan innan att 1.1 + 2.1 ger 3.3000000000000003, jag testade att addera (2.1 + 2.1) tre gånger dvs. 1.1 + 2.2 + 1.1 + 2.2 + 1.1 + 2.2 (jag använder inte multiplikation för att jag vet inte om den operatorn ställer till problem i det här fallet), det jag får blir 9.900000000000002, men detta är inte korrekt upp till 16 värdesiffror? Den 16:e siffran är 2 vilket inte borde vara där? Min naiva förväntning var att flyttal som adderas skulle vara korrekt upp till 16 värdesiffror?

Är detta för att man adderar talen 1.1 och 2.2 i bastvå (som redan är approximationer av 1.1 och 2.2) och representerar den summan i bas 10? 

Orsakar inte detta problem även när man summerar flyttal? Jag trodde att flyttal orsakade mest huvudvärk när man undersökte differensen av två väldigt nära tal och när man adderade två väldigt olika stora tal m.m. men inte vid addition av lika stora tal?

Jag frågar eftersom jag vill kolla om mitt lilla experiment var rätt och om jag då kan rättfärdigt dra slutsatser från resultatet.

Du har rätt i väldigt mycket!

Som de andra har varit inne på så finns det många (oändligt många) tal som har en exakt representation i bas 10 som inte har det i bas 2. Detta gäller för alla baser. I basen 12 kan du t.ex. representera $\frac{1}{3}$ exakt men det går inte i basen 10. Alla dessa tal måste avrundas för att kunna representera dem i bas 2. Du kanske redan var med på det här.

När du sedan gör beräkningar med dina avrundade tal så ökar avrundningsfelet. Det kan öka lite grand eller jättemycket beroende på beräkningen. Och det beror inte på att du har med en dator att göra. Det är helt enkelt så det blir. Antag t.ex. att du har mätt 2 sträckor med ett måttband. Du har fått värdena $1,534\pm 0,003 m$ och $0,876\pm 0,003 m$. Dvs det du mätte eller det du mätte med gjorde så att det inte gick att avgöra måttet noggrannare än på 3 mm upp eller ner. Om du då summerar (eller subtraherar) dessa mått så får du $2,410\pm 0,006$ (eller $0,658\pm 0,006$) eftersom du måste ta höjd för "värsta fallet". Osäkerheten har alltså ökat. På samma sätt (ungefär) är det i en dator. Alla tal som inte fick en exakt representation kommer att ha en osäkerhet i sig och den kommer att fortplanta sig (och öka) i beräkningar. Om det vill sig illa (beroende på vad du gör med talen) kan osäkerheten öka exponentiellt!

Ditt exempel med att subtrahera 2 stora tal är ett exempel där osäkerheten blir tydlig eftersom resultatet av beräkningen kan vara i samma storleksordning som osäkerheten. Det kan betyda att man inte kan lita på resultatet alls.

Den här typen av problematik studerar man på universitetet i något som kallas numerisk analys. Osäkerheter är kanske inte ett helt matematiskt område men en del av den numeriska analysen handlar om osäkerheter och störningsteori.

Peter skrev:

Du har rätt i väldigt mycket!

Som de andra har varit inne på så finns det många (oändligt många) tal som har en exakt representation i bas 10 som inte har det i bas 2. Detta gäller för alla baser. I basen 12 kan du t.ex. representera $\frac{1}{3}$ exakt men det går inte i basen 10. Alla dessa tal måste avrundas för att kunna representera dem i bas 2. Du kanske redan var med på det här.

När du sedan gör beräkningar med dina avrundade tal så ökar avrundningsfelet. Det kan öka lite grand eller jättemycket beroende på beräkningen. Och det beror inte på att du har med en dator att göra. Det är helt enkelt så det blir. Antag t.ex. att du har mätt 2 sträckor med ett måttband. Du har fått värdena $1,534\pm 0,003 m$ och $0,876\pm 0,003 m$. Dvs det du mätte eller det du mätte med gjorde så att det inte gick att avgöra måttet noggrannare än på 3 mm upp eller ner. Om du då summerar (eller subtraherar) dessa mått så får du $2,410\pm 0,006$ (eller $0,658\pm 0,006$) eftersom du måste ta höjd för "värsta fallet". Osäkerheten har alltså ökat. På samma sätt (ungefär) är det i en dator. Alla tal som inte fick en exakt representation kommer att ha en osäkerhet i sig och den kommer att fortplanta sig (och öka) i beräkningar. Om det vill sig illa (beroende på vad du gör med talen) kan osäkerheten öka exponentiellt!

Ditt exempel med att subtrahera 2 stora tal är ett exempel där osäkerheten blir tydlig eftersom resultatet av beräkningen kan vara i samma storleksordning som osäkerheten. Det kan betyda att man inte kan lita på resultatet alls.

Den här typen av problematik studerar man på universitetet i något som kallas numerisk analys. Osäkerheter är kanske inte ett helt matematiskt område men en del av den numeriska analysen handlar om osäkerheter och störningsteori.

Hej Peter, tack för svaret! Jag håller faktiskt på med numerisk analys (eller det heter numeriska metoder för oss?) som kurs just nu. Jag inser nu att jag kanske borde ha noterat att det var lite mer på universitets nivå, även om frågan kan förstås av de flesta som håller på med python.

Från det du skrev tolkar jag det som att experimentet jag utförde då talar för (även om det självfallet inte är ett bevis) mitt resonemang?: "[...] adderar talen 1.1 och 2.2 i bastvå (som redan är approximationer av 1.1 och 2.2) och representerar den summan i bas 10?"

En annan viktig sak som jag inte ser tagits upp är. Tal som 1.1 (som inte representeras exakt i datorn) representeras alltid på samma sätt i datorn (som används). Det vill säga i den dator som används blir alltid 1.1 + 1.1 samma resultat. Till exempel i en dator är inte

2/3 + 1/3 = 1

som vi är vana vid men

(1 - 1/3) + 1/3 = 1

eftersom 1/3 alltid representeras på samma sätt i datorn. Numerisk analys kanske inte är en datorfråga kom jag på nu?

Är detta för att man adderar talen 1.1 och 2.2 i bastvå (som redan är approximationer av 1.1 och 2.2) och representerar den summan i bas 10?

Jag håller med om det. Här har 2 fel adderats och blivit större (än vad du förväntade). I Aerius 2:a exempel får man ett exakt svar trots att de ingående variablerna inte är exakta. Felen tar ut varandra.

Jag tycker att Aerius inlägg är mer spot on än mitt eftersom det handlar om representation av talen i datorn. Mitt resonemang handlar mer om osäkra mätningar i allmänhet (å andra sidan kanske 1,1 och 2,2 är just mätningar).

Aerius skrev:

En annan viktig sak som jag inte ser tagits upp är. Tal som 1.1 (som inte representeras exakt i datorn) representeras alltid på samma sätt i datorn (som används). Det vill säga i den dator som används blir alltid 1.1 + 1.1 samma resultat. Till exempel i en dator är inte

2/3 + 1/3 = 1

som vi är vana vid men

(1 - 1/3) + 1/3 = 1

eftersom 1/3 alltid representeras på samma sätt i datorn. Numerisk analys kanske inte är en datorfråga kom jag på nu?

Är det? Jag hade för mig tvärtom, 1/3 + 2/3 är 1 i och med IEEEs avrundningsregel. Jag kanske missminner mig dock. :)