Räknefel i Kalkylatorn

Var gör du den multiplikationen?

Och varför ställer du frågan i en tråd som handlar om Svenska MacWorld?

Förklara gärna frågan lite närmare, så kan vi kanske flytta den till ett forum där den passar lite bättre.

/Mod

Frågan flyttad till en egen tråd i ett mer lämpligt forum.

/Mod

Binära talsystemet har problem med vissa tal, precis på samma sätt som vårt decimala talsystem inte heller kan representera vissa tal på ett tillfredsställande sätt. Skulle jag till exempel sätta dig på att först räkna ut vad tio delat på tre är, för att sedan be dig multiplicera ditt svar med tre, får du inte längre tio. Och det beror inte på att du är puckad, utan på att räkneuppgiften är det.

Ungefär samma sak gäller här, fast med ett talsystem baserat på 2, så det är inte kalkylatorns fel. Fast kalkylatorn i Leopard verkar avrunda lite mer nitiskt för att dölja sånt här... antar att du kör någon äldre version? Vill minnas att kalkylatorn förut hade problem med 10 - 0,9 - 0,1 också...

Va? Menar du att 1625800,00000000023 är rätt eller vad? Jag säger att kalkylatorn räknar fel, punkt.

Jag får 73,90 * 22 000 = 1 625 800

Det får jag också.

Gör jag samma beräkning i matlab så blir felet som dyker upp 2.3283e-10, vilket stämmer bra med vad miniräknaren felar med - som samuel k säger, numerisk representation på datorer, sk ändlig aritmatik, inget konstigt alla datorer har denna sorts betende. Får det dock inte med min miniräknare -vilket os kör du ?

Excel ger 1625800,000000000000000000000000000000.

Excel är programmerat för att vara allert på betendet - samma sak med min version av miniräknaren - men jag lovar att det är inte ett räknefel från programmet, eller datorn. Dom har i dessa program lagt in en regel på följande typ: om dom x första decimalerna är 0 så är talet ett heltal.

Om du inte tror på betendet så kan jag rekomedera en kurs i numeriska metorder

Så du påstår att 73,90 * 22000 faktiskt blir 1625800,00000000023...? Jag säger att det är fel och det beror på dålig programering.

Excel är inte så bra att ha som "facit" då Excel, som de flesta andra liknande program, har sina inbyggda "räknefel". Du har fått förklaringar till varför så det räcker väl med det.

Jag vet vad problemet är och menar att om en räknare ger svaret 1625800,00000000023 på frågan 73.9 * 22000 så är den dåligt programmerad (av flera anledningar, inte bara precisionen utan avrundningen).

Nu får in hålla med lite!

PS. Excel är uppenbarligen bäst hittills…

På exakt det talet ja. Men det säger väl inte så mycket om braigheten i stort?

Det där beror på att datorer normalt lagrar flyttal i binärform och att många reella tal inte kan representeras exakt av en ändlig mängd binära siffror. Det gör att man tappar precision, men så länge talen inte är alltför stora gör det normalt inget. När man verkligen behöver precision använder man andra datatyper, men de tar normalt upp mer minne och är långsammare att arbeta med.

Detta syns tydligt i följande exempel. Två flyttal multipliceras och produkten skrivs sedan ut med 20 decimaler. När jag testar ger det 1625800.00000000023283064365.

#include <stdio.h>
int main (void)
{
        double x = 73.9 * 22000;
        printf("%.20f\n", x);
        return 0;
}

Applescript:
1.6258E+6

Så...datorer räknar fel och vi har nu fått veta varför. Då får man ju verkligen hoppas att astronomerna och kvantfysikerna vet detta och att dom då använder speciell mjukvara som kan lura datorn att räkna rätt.

Oh ja! Vore ju sorgligt om vi skickade rymdraketer på Mars och missade.

Du har redan fått svaret i tråden. När precisionen är viktig använder man datatyper som tillåter mkt hög precision. Apple utgår förmodligen ifrån att man inte beräknar rymdfarkosters bana med kalkylatorn

testade just med räknaren i Dashboard på OSX, den ger rätt.

HP 49:an ger

73,9 ENTER 22000 X
1625800

Minräknarprogrammet "42" på min iPhone ger rätt.
iPhones egen räknare ger rätt

Det var då själva fan...

Startar mathematica; 1.6258000000000002`*^6 när jag TVINGAR programmet göra en Numerate Expression. Förmodligen ligger inte felet i beräkningen i sig utan i funktionen Numerate.

Frågan är ju egentligen varför kalkylatorn ger dig (Fahlander) ett svar med 12 decimaler.

Och en dators precision är inte exakt, eftersom tal representeras diskret, som många redan har påpekat. Däremot är de reella talen kontinuerliga och överuppräkneliga (det finns oändligt många, även inom ett visst intervall). Ett 64-bits heltal i datorn kan däremot bara ha 2^64 olika värden.

Det värde du får är så nära man kommer när man, av någon anledning, använder 12 decimaler.

Jag minns en gammal TI-30s med som jag lånade av brorsan när han gick i gymnasiet. Om man bad den om ett irrationellt tal gav den det med typ 8 värdesiffror, t.ex. 2.7182818, subtraherade man 2.7182818 så gav den ändå 2.84E-08.
Den räknade alltså internt med 11 siffrors precision men visade bara 8. Räknaren i början av tråden gör alltså tvärtom, vilket inte verkar speciellt genomtänkt. Eller snarare, hur kom den buggen till??

Du som är datavetare förresten, kan man säga något om processorn, registerstorlek eller liknande? 40 bitar verkar udda eller är jag ute och cyklar nu?

Visar man Paper Tape så står det: 73.900000000000006*22000 =1625800. Trots att jag skrev in 73,90 i räknaren. Så något lurt är det ju... Dags för buggrapport!

Det luriga är att datorer använder binär representation för tal. Den enda buggen jag kan se är att man eventuellt visar fler siffror i precision än vad man har täckning för.

I decimal representation (som vi människor är vana vid) så kan en del bråk inte skrivas exakt.
1/3 blir 0,3333.... (Se inlägg 7 i denna tråd). Om man multiplicerar 0,3333.... med 3 får man 0,9999... och inte 1. En bugg!!!!

Datorer använder binär representation, bara ettor och nollor. I det decimala systemet kan man skriva t.ex. 1/10 exakt. Det blir 0,1. Men i det binära talsystemet finns ingen exakt representation det blir: 0,000110011... Och därför blir det heller inte 1 om jag skulle multiplicera detta tal med det decimala talet 10 (1010 binärt).

(0,0001100110011... kan tolkas som 1/16+1/32+1/256+1/512+1/4096+1/8192... vilket inte blir riktigt 0,1. Med ett ändligt antal termer kommer du aldrig fram till summan 0,1.)

Det går naturligtvis att representera tal decimalt i datorer (i mjukvara, hårdvaran har inget stöd). Då kan tal som 0,1 eller 73,9 representeras exakt, men fortfarande inte 1/3. Hade vi valt basen 12 kan vi representera 1/3 exakt (0,333... decimalt, 0,4 i basen 12) men inte 1/5 (0,2 decimalt, 0,24972497... i basen 12). Det finns alltså inget som gör basen tio mer exakt än någon annan bas.

COBOL samt vissa SQL-databaser har stöd för decimal representation av tal.

Tack pesc, glasklart - så som bara du kan.