Svenska ElektronikForumet

round() i all ära - men för vidare arbete med värdet kan float-problemet komma upp igen.
En avrundning till t.ex. 2 decimaler blir likaväl en float vilket igen ger problem med exakta värden.

Å jag som trodde datorer var bra på nummer/matte.

De kan ju bara ettor och nollor! Så vad kan du förvänta dig?
Eller som en jornalist skrev inför milleliumskiftet. Det blir värre när de skall få plats med tvåor också!

Datorer ÄR bra på att räkna, men det är inte alltid programmerarna har koll på numeriken. Många är de som trott att flyttal är "rätt" och därefter gått på pumpen.

64-bitars IEEE-flyttal är en bra kompromiss, men man måste minnas att de är just det, en kompromiss mellan hastighet, lagringsutrymme, energi och noggrannhet.

Jag råkade se något som jag tyckte var tillräckligt underbart för att platsa här, även om det är en bit off topic.
Lite på tal om hastighet för flyttalsberäknngar...

FLOATING-POINT PACKAGE FOR
INTEL 8008 AND 8080 MICROPROCESSO

https://www.retrotechnology.com/herbs_s ... 008fpp.pdf

Jag kom på att jag har gjort ett mattepaket för en minidator för länge sedan. sin, cos, exp och liknande. Då var det viktigt att ha koll på precisionen i flyttalsberäkningarna.

/Pi

Det här är vad jag förväntar mig att en normal dator gör om den får tid på sig. Direkt i alla programspråk.
In 2019, we calculated 31.4 trillion digits of π.
https://cloud.google.com/blog/products/ ... ogle-cloud

sodjan skrev: ↑9 juli 2022, 14:56:36 EDIT2: Du ser ut att köra en V3. I V2.7.8 ger det "rätt" svar. Inte en susning varför, men:

En snävare avrundning i print. 0.1 och 0.2 (0,1 och 0,2 på svenska) går jämnt ut i en decimal division, men precis som 1/3 får en oändlig mängd decimaler, så blir det oändligt många "bimaler" i 1/5.
1/3 med 4 decimaler blir 0.3333. Multiplicerar vi det med 3 blir det 0.9999, alltså inte 1. Tar vi n decimaler, så blir det fortfarande fel motsvarande den sista decimalen, oberoende på hur stort n vi väljer.

Utan att gå in på jee-jee flyttalsdetaljer, så har vi bara exempelvis 64 bits att tillgå, så det blir alltid en avrundning när man konverterar från decimaltal, om det inte råkar gå jämnt ut (som t.ex. 0.5 och 0.75).

Divisioner:

Du kan titta på decimal lib
https://docs.python.org/3/library/decimal.html

Det här är vad jag förväntar mig att en normal dator gör om den får tid på sig. Direkt i alla programspråk.
In 2019, we calculated 31.4 trillion digits of π.

Det har inte direkt med programspråket att göra, utan snarare vilken datatyp man använder för att representera tal. De flesta vill inte ha en jätteoverhead i alla beräkningar utifall man möjligen vill beräkna pi med miljarder decimaler utan föredrar att "vanliga" beräkningar går snabbt och effektivt. Därav kompromissen. Det finns lastbilar och det finns racerbilar. De är bra på olika saker.

Prova räkna stora heltal med Python istället och låt dig förundras!

Om man för ett ögonblick bortser från dom behov som föreligger om man ska beräkna pi med miljardtals decimaler, så kanske man kan sammanfatta det ungefär så här?

I datorer är dom vanligaste talsystem som används dessa.
– Heltal.
– Flyttal.
– Decimala tal, ofta med ett fixt antal decimaler.

Typiska tillämningar, när dessa används är.
– Matematiska beräkningar där heltalsvariabler ingår.
– Fysikaliska eller tekniska beräkningar.
– När ekonomi hanteras, såsom av banker och i redovisningssystem.

Alla alternativ har styrkor och svagheter. Precisionen kan variera, men några få alternativ är väldigt vanliga.
Här är några exempel.
– 8, 16, 32 eller 64-bits heltal.
– 32 eller 64-bits flyttal.
– 64-bitars heltal, skalat t.ex. en faktor 100.
– Decimal lagring, t.ex. med 4 bit per decimal siffra.

Programmeringsspråk har ofta stöd för val av talsystem och några alternativ för noggrannhet eller max storlek på tal som kan lagras. Man väljer som programmerare efter aktuellt behov.

Det senaste så att talet representerar t.ex. ören eller cent även om det i huvudsak handlar om t.ex. kronor eller dollar.

Detta med pengar påminde mig om något "roligt" som måste ha ställt till det lite när det skulle programmeras.

Until 1971, British money was divided up into pounds, shillings and pence. One pound was divided into 20 shillings. One shilling was divided into 12 pennies. One penny was divided into two halfpennies, or four farthings.

https://www.nottingham.ac.uk/manuscript ... money.aspx

Under ganska lång tid fanns både gamla mynt, där baserna var 20 och 12, och nya mynt, där basen var 100. Då fanns det gamla pence och nya pence, som hade helt olika värde.

/Pi

Alltså jag förstår att tal som 10/3 måste avrundas någonstans annars skulle program aldrig komma vidare.
MEN:
10.1 + 10.2 är 10.3! Det finns inget efter första decimalen så det behöver inte avrundas.

Men nu skiter jag i det för det fanns en lösning på problemet
import decimal
from decimal import Decimal
x = Decimal('0.1')
Så får man använda Decimal istället för int eller float.

När man använder den här import funktionen. Vart ligger dom här classerna som man hämtar? Sticker Pycharm ut på nätet och hämtar om man behöver något som inte är "standard" eller hur gör man?

För att "Import" ska fungera så behöver modulen vara med i Python installationen som man kör.
Den finns alltså redan där i din dator, men om man alltid skulle ladda alla hundratals Python
moduler med automatik, så skulle uppstarten bli seg och minnesbehovet större. Därför laddar
("importerar") man de moduler (som inte är inlänkade i grunden) vid behov.

EDIT:
Jag vet inte var decimal.py ligger i just din installation, men det kan se ut så här i en annan:
Filen decimal.py (eller .pyc, om den finns) är det som läses in då du gör "Import". Kolla gärna i filen för lite mer bakgrund och dokumentation...

> 10.1 + 10.2 är 10.3

Ja, men om du använder float, så är 10.1 och 10.2 bara approximationer internt.
Det är inte exakt 10.1 resp 10.2 som du tycks tro...

Begrunda mitt tidigare inlägg en gång till och notera att talen inte lagras decimalt, de lagras binärt.
\(0.2=\frac{1}{5}=\frac{0b1}{0b101}=0b0.001100110011001100110011001100110011001100110011...\)

Det är inga problem att få datorer att räkna exakt rätt med decimaler om man använder rätt verktyg, men floats och doubles är inte exakta och har aldrig varit tänkta att vara det.

Vill man representera decimaler exakt, så har man i praktiken två val - antingen hanterar man det själv med fixed point och eller så använder man GMP (med den integration man har i språket man föredrar).