Het schijnt dat nou juist rekenen zo lastig is omdat het moeilijk te testen is. Er is een oneindig aantal mogelijkheden die dus ook oneindig veel fouten kan bevatten, maar waar?
Fouten in calculators en spreadsheets op computers komen vaker voor dan je denkt. Ik kwam laatst nog zo'n leuke grapje met Excel ergens tegen, dan valt je mond ook open van verbazing. Ik zal even kijken of ik hem kan vinden...
Edit: dit dus.
Try this:
In a new spreadsheet, give the cell A1 the value of 0.2
In A2 enter the formula '=A1*6-1' (the calculated value will also be 0.2)
Then copy this formula to A3 down to ca A40.
For every cell you should get 0.2 as a result, since 0.2 (the result of the cell above) times 6 minus 1 is 0.2. Right?
Right? Try it in Excel, try it in Mesa, try it in Google Spreadsheets.
And then repeat after me:
"I will never again blindly believe in spreadsheet calculations"
Dat gedrag is misschien onverwacht voor veel mensen, maar het is niet direct een bug. Wanneer een processor met floating point getallen rekent slaat hij ze nu eenmaal op in de vorm van x*2^y (fixed, tnx Japs). Als je 0,2 op die manier uitdrukt kun je dat al nooit helemaal perfect doen, laat staan iets als 1/3. Afrondingsfouten zijn dus inherent aan iedere FPU die op die manier werkt (wat bij Intel, en AMD en de meeste andere merken het geval is) en zijn zelfs zorgvuldig gestandaardiseerd, zodat men er rekening mee kan houden. Als je dat niet doet en het zichzelf exponentieel laat versterken kom je inderdaad in de problemen, maar dat is dan meer te wijten aan je programmeerkennis en -kunsten dan aan de onbetrouwbaarheid van de computer (die maakt namelijk keer op keer precies dezelfde 'fout').
Voor bepaalde financiële software is het in Amerika overigens bij wet verboden om normale FPU-instructies te gebruiken, die moeten verplicht met decimale getallen rekenen. IBM-mainframes versnellen dit hardwarematig.
@4VAlien: klopt, maar het is voor veel mensen wel een beter begrijpelijk voorbeeld, aangezien 1/3 ook in decimalen oneindig lang is.
Dat gedrag is misschien onverwacht voor veel mensen, maar het is niet direct een bug.
maar dat is dan meer te wijten aan je programmeerkennis en -kunsten dan aan de onbetrouwbaarheid van de computer
Dat is in mijn boekje toch een bug hoor. Het programma komt niet met de gewenste resultaten door programmeerkennis en -kunsten = bug.
lijkt me een standaard floating point afwijking. Kan het zo gauw niet testen, maar ligt het in de orde van 10^-20 oid ? Dat is toch wel triviaal voor dagelijks gebruik. Er bestaan speciale exacte datatypen, ook in Excel om dit te voorkomen. Dit is vooral voor de financiele sector van belang en daar wordt dus wel op getest.
@wouter tinus: er is geen reden om aan te nemen dat je 1/3 slechter kan benaderen dan 0.2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,22
0,31
0,85
4,1
23,58
140,48
841,91
5050,43
30301,6
181808,61
1090850,67
6545103,02
39270617,13
235623701,79
1413742209,71
8482453257,27
50894719542,64
305368317254,84
1832209903528,02
10993259421167,1
65959556527001,8
.................
Bij jou gaat 't wel heel erg mis, bij mij zijn de verschillen veel kleiner:
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,2
0,200000002
0,200000011
0,200000064
0,200000387
0,20000232
0,20001392
0,200083522
0,20050113
0,203006779
0,218040672
0,308244034
0,849464205
4,096785231
(Excel 2003, Win XP, Core Duo)
Bij jou gaat 't wel heel erg mis, bij mij zijn de verschillen veel kleiner
Huh? Bij jullie beiden zit je bij het 23e getal op 4.. wat is het verschil?
@zero4cool & Onno:
Dezelfde lijstjes, alleen is de ene op 2 decimalen afgerond en de andere niet.
Hier nogmaals 't zelfde lijstje, maar dan met 16 decimalen:
0,2000000000000000
0,2000000000000010
0,2000000000000060
0,2000000000000380
0,2000000000002300
0,2000000000013810
0,2000000000082880
0,2000000000497270
0,2000000002983600
0,2000000017901580
0,2000000107409510
0,2000000644457030
0,2000003866742190
0,2000023200453140
0,2000139202718860
0,2000835216313130
0,2005011297878810
0,2030067787272860
0,2180406723637130
0,3082440341822800
0,8494642050936810
4,0967852305620900
Vul eens dit in in een willekeurige cel:
=0,2*100000000000000-19999999999999,8
Er zou gewoon 0,2 moeten uitkomen.
Dit komt eruit: 0,19921875
Hallo,
Het gaat inderdaad mis. Een heel erg mooi voorbeeld! Ik zou dit niet verwacht hebben omdat je alleen 'onschuldige' integers gebruikt en niet aan het delen slaat. Intern wordt er blijkbaar echter met een zwevende komma gerekend.
Wat het voorbeeld laat zien is dat ogenschijnlijk een exact resultaat onder water in werkelijkheid niet exact is. Vervolgens wordt iedere volgende iteratie verder gerekend met het niet exacte resultaat.
Na 18 iteraties heb je al een fout in de derde decimaal te pakken. Help! Na 20 iteraties lijkt het resultaat nergens meer op. Na 29 maal heb je de lotto gewonnen.
(eerst het nummer van de iteratie, dan het reulstaat:)
0,2
1 0,2
2 0,2
3 0,2
4 0,2
5 0,2
6 0,2
7 0,2
8 0,2
9 0,2
10 0,200000002
11 0,200000011
12 0,200000064
13 0,200000387
14 0,20000232
15 0,20001392
16 0,200083522
17 0,20050113
18 0,203006779
19 0,218040672
20 0,308244034
21 0,849464205
22 4,096785231
23 23,58071138
24 140,4842683
25 841,9056098
26 5050,433659
27 30301,60195
28 181808,6117
29 1090850,67
30 6545103,022
31 39270617,13
32 235623701,8
33 1413742210
34 8482453257
35 50894719543
36 3,05368E+11
37 1,83221E+12
38 1,09933E+13
39 6,59596E+13
Natuurlijk kun je dit oplossen door altijd rechtstreeks aan de bron te refereren. Maar de lol van rekenbladen is nu juist dat je kunt doorrekenen op tussenresultaten. En die neiging wordt versterkt doordat het niet wenselijk is om erg complexe formules in één cel te proppen.
Hoe dit dan wel goed op te lossen?
Het eerste wat bij me opkomt is de tussenresultaten af te ronden.
=round(a3*6-1;5)
Tot mijn grote verbazing levert dit dezelfde fouten op. Round werkt dus blijkbaar alleen op de presentatie. Hier zou ik dus echt compleet mee de mist in zijn gegaan.
Eentje die wel werkt:
=FIXED(D1*6-1;3)
Dit is echt 'programmeren met de brandslang'. Fixed zet het resultaat om in tekst. Dus iedere volgende keer wordt eerst de tekst weer omgezet naar een numerieke waarde voor er weer mee gerekend wordt.
Beste Maurits, dank voor je bijdrage, ik had niet gedacht dat dit probleem zich nu nog in deze mate zou manifesteren.
Het gaat inderdaad mis. Een heel erg mooi voorbeeld! Ik zou dit niet verwacht hebben omdat je alleen 'onschuldige' integers gebruikt en niet aan het delen slaat. Intern wordt er blijkbaar echter met een zwevende komma gerekend.
ahum. 0.2 is bij mijn weten geen integer getal, maar wel een floating point getal.
De afrond functie in mijn Excel 2002 doet het (raar genoeg?) wel goed
=AFRONDEN(A1*6-1,5)
Leuk voorbeeld, maar zoals velen al zeiden is dit gewoon te verklaren.
Toen ik destijds naar de univ ging, was een van de examens 'numeriek rekenen' en ging juist over deze problematiek. Hierbij moest je onder andere de maximale afrondingsfout van een bepaalde wiskundige uitdrukking kunnen berekenen gegeven de nauwkeurigheid van de rekenmachine/computer. En soms kwam je inderdaad wel tot heel verrassende resultaten zoals deze spreadsheet truuk mooi illustreert (cel A30 heeft al een waarde van meer dan 1 miljoen ipv 0.2!!!).
Vandaag is de computer echter zo ingeburgerd dat niemand er nog stil bij staat dat computers eenmaal met een beperkte nauwkeurigheid rekenen en die fouten zich kunnen verder zetten tot gigantische proporties.
'tzal je waarschijnlijk ten zeerste verbazen, maar de meeste excel gebruikers hebben geen cursus `numeriek rekenen' gehad.
Leg de schuld waar je wil, maar een doordeweeks pakket moet rekening houden met de doordeweekse gebruiker. Er zijn nu zoveel bedrijfskritische excel sheets --- vaak waar de originele schrijver niet meer werkt bij hetzelfde bedrijf en dus de kennis van de specifieke valstrikken verloren is.
Ik herinner me vaag een rapport 2-3j geleden met een schatting van het aantal miljarden op wereldschaal dat hiermee geriskeerd wordt. Rekenfouten worden pas ontdekt als het spectaculair misgaat (je voorspelde inkomsten zijn orde van grootte van het BNP, of je shuttle crasht), afwijkingen van 5--10%, hoe herken je die? Beats me.
tzal je waarschijnlijk ten zeerste verbazen, maar de meeste excel gebruikers hebben geen cursus `numeriek rekenen' gehad.
Er steekt meer achter deze simpele opmerking dan je zelf waarschijnlijk kunt vermoeden. Machine accuracy is op zich een vrij bekend probleem.
Het feit dat we de computer voor steeds meer dingen gebruiken, maar dat we gebruikers steeds minder mogen opvoeden verdient nu niet echt de schoonheidsprijs. Onder het motto dat elke idiote mong**l er mee moet kunnen werken, verzwijgen we elementaire problemen.
In plaats van slimmer zijn computer gebruikers gemiddeld veel en veel minder slim geworden het afgelopen decennium. Ik hoorde laatst dat men de huidige generatie de 'generatie einstein' noemt, omdat men weet hoe de muis bewogen moet worden en hoe een email te verzenden. Generatie dombo zou af en toe meer op z'n plaats zijn. Men is te lui om basis kennis te leren over het geen men gebruikt, want alles moet gewoon lekker automatisch werken. Bij Shanna van 18 die bij een bedrijf met excel gaat werken hoef je niet aan te komen met numerieke theorie. "Bah! Wiskunde! Daar heb ik geen trek in hoor. Das voor nerds! Veel te moeilijk." Je hoort het haar al roepen.
En dat noemt zich dan de generatie Einstein.
Onzin... De numerieke wiskunde is een discipline die al heel ver gevorderd is in het voorspellen van fouten. Je kan heel makkelijk een aantal algorithmes uitvoeren, en kijken of je fout binnen de conditie van je probleem valt, icm de stabiliteit van je methode. Zoniet, zijn er grote afrondingsfouten gebeurd bij elementaire bewerkingen.
Voor nog een mooi voorbeeldje van afrondingen: 0.1 + 0.1 + 0.1 - 0.1 - 0.1 - 0.1 is ongeveer gelijk aan de machinenauwkeurigheid van een computer (10^-16 voor IEEE-floating point getallen)
Als ik het goed begrijp is het probleem van foutopsporing in calculators en dergelijke vooral de extreme hoeveelheid mogelijke testcases.
Afrondfouten zijn te verwachten en te voorspellen, dat valt nog wel mee. Maar wat nou als er echte bugs in een calculator zitten, waar zitten die dan? Hoe kom je daar achter?
Je kunt de uitkomst van 1+1 testen, de uitkomst van 27+31 testen en de uitkomst van 123+321 testen. Maar bewijst dit dan ook dat de uitkomst van 4287488794391+234554356245 goed zal zijn? En dit is alleen nog maar optellen...
Wat nou als een programma alleen door een stomme programmeerfout een probleem heeft bij het vermenigvuldigen van een getal met 16 decimalen met eentje met 17 decimalen, alle andere aantallen decimalen gaan prima? Hoe groot is de kans dat je dat ontdekt?
@Maurits:
Dan is dat niet zozeer een programmeerfout, als wel een software-ontwerp fout. En een heel onlogische.
Want de berekeningen op de getallen moeten op alle getallen op dezelfde manier gebeuren. Dus als 't fout gaat, moet 't ook bij alle getallen fout gaan.
Nog meer offtopic
De rekenmachine van Windows is ook verwarrend, als je 1 + 2 * 3 intypt op standaard (uitkomst = 9) en wetenschappelijk (uitkomst = 7). Op wetenschappelijk wordt Meneer Van Dale Wacht Op Antwoord wel aangehouden, op standaard niet.
Leuk als je aan de telefoon een som probeert uit te leggen en je krijgt beide een ander antwoord.
@Vaan Banaan
Dat is best wel erg lomp
, het "Meneer Van Dale.." is rekenen op basisschoolniveau, en toch doet Windows dat fout. De Mac doet het hierin juist wel weer goed (uitslag 7), evenals de standaard calculater in Kde (KCalc).
@Datafeest:
Calc simuleert gewoon een goedkope calculator. Zoeen zonder sin/cos/tan en zo. En die houden normaalgesproken ook geen rekening met MVDWOA.
Dus omdat het een 'goedkope calculator' is geeft die rekenmachine maar foutieve antwoorden?
Waarschijnlijk heb jij wel gelijk, dat MS op die manier dat bepaald heeft, maar daarom is het nog wel erg raar.
De Windows Calc doet het prima, zet hem alleen even in "Scientific" mode i.p.v. de standaard mode. Nogal vreemd dat dit nodig is eigenlijk.
@Frank-L:
Wat doen die knoppen:
SIN, COS en TAN dan bij mij in calc.exe? ;-)
We hadden het toch over de niet-scientific mode van calc?
Wat ik zo gek vind is dat als ik in mijn TI-83 0,2 intik, op enter druk, en daarna:
Ans * 6 - 1 en daarna een paar keer op enter druk (naja, stuk of 30 keer) er geen enkele fout optreed...
Heeft dit dan te maken met het aantal bit dat je een proccesor ook mee werkt??
In excel doet de fout zich overgens wel voor...
Rekenmachines zijn gemaakt om met decimale getallen de juiste uitkomst te geven. Met dit soort problemen is dus juist extra rekening gehouden. Ik zal het een keer door laten rekenen in een getallenrij op mijn TI-83+SE, kijken wat ie dan roept.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
10:59
10:12
Door 
) en wordt er vaak geen rekening gehouden met het feit dat de verantwoordelijkheid uiteindelijk ligt bij de mens: de ontwikkelaar van de soft- / hardware.
.)
