Afrondingsfouten in MacOS X 10.4.8

De recent uitgebrachte update MacOS X 10.4.8 heeft niet alleen problemen opgelost, maar ook een vervelende nieuwe geïntroduceerd. Verschillende PowerPC-applicaties zijn namelijk afrondingsfouten gaan maken op Intel-hardware, wat in twee bekende gevallen directe invloed op gebruikers heeft. De eerste is de schoolsoftware PowerGrade: leraren in de Amerikaanse staat Utah merkten dat de cijfers van hun studenten ineens verkeerd werden afgerond. Het tweede slachtoffer is het databasepakket 4D, dat volgens de makers sinds de update niet nauwkeurig genoeg meer met invoer omspringt. In beide gevallen krijgen de wiskundige functies van Rosetta de schuld. Het probleem heeft echter de potentie om nog veel breder verspreid te zijn: mensen zijn nu eenmaal gewend om blindelings te vertrouwen op de rekenkunsten van de computer.

Apple heeft het probleem onderkend en werkt aan een patch om de nauwkeurigheid van OS X in ere te herstellen. Vooralsnog is er echter geen officiële oplossing beschikbaar, waardoor in het geval van de leraren wordt geadviseerd om de 10.4.8-update niet te installeren of zelfs te verwijderen. Een minder drastische oplossing is de tijdelijke pleister die op de website van 4D is te krijgen. Deze zet de wiskundefuncties van 10.4.7 terug. Hoewel de oudere versie volgens de bijsluiter van dat medicijn ook niet perfect is, zijn de fouten daarin in ieder geval 'veel minder ernstig'.

Terug naar de schoolbanken...

Reacties (82)

[Anoniem: 190996]

Wow! Dit is echt wel heel erg.

Afrondingsfouten in applicaties komen nog steeds regelmatig voor. Maar op het niveau van het besturingssysteem - nou vooruit, Rosetta is één laagje daarboven - is wel erg vervelend.

Vroeger werd er geleerd om zoveel mogelijk afrondingsproblemen te vermijden bij het programmeren door bijvoorbeeld altijd te testen op deze wijze:

if (a < 3) {}
*deze werkt als a niet precies 2 is *

in plaats van

if (a == 2) {}
* deze faalt als a = 1.9999999999 *

Maar met het beter worden van de machines is die praktijk aardig in onbruik geraakt. Fouten kunnen daarom op veel meer plaatsen optreden dan alleen op plaatsen waar een getal wordt gepresenteerd.

Laat Apple maar heel erg snel patchen.

Het belooft een leuke dag te worden voor alle Microsoft fans. (En die zijn daar wel aan toe .)

[Wouter Tinus]

Wat jij beschrijft komt inderdaad voor, alleen het is niet echt een 'fout' maar meer een beperking van de techniek. Er zijn namelijk wel standaarden (zoals IEEE 754) die precies beschrijven hoe afronding moet werken, inclusief die imperfecties waardoor je antwoorden als 1.999999999 krijgt in plaats van precies 2. Apples probleem daarentegen is veel ernstiger: in het geval van de schoolsoftware zaten cijfers er niet een miljoenste maar een tiende naast. Lijkt voor sommige mensen nog steeds niet heel significant, maar het zou voor iemands boekhouding of een wetenschappelijke simulatie na een paar iteraties toch rampzalig kunnen worden. Het gaat kennelijk lang niet altijd fout (anders was het veel eerder ontdekt), maar toch zijn dit hele geniepige bugs waar een fabrikant zich flink voor zou moeten schamen.

[Madcat]

waarom zou a<3 falen als a een floating point is?
maar je hebt wel gelijk dat het een heel raar probleem is wat vaak fout gaat.

in c# zit ook nog een heerlijke bug.
als je een string met de waarde "0.7" bijvoorbeeld cast naar een float, dan krijg je er ook 0.69999... uit. ipv 0.7

maar over het algemeen moet je floating points zo veel mogelijk vermijden

[AntiChris]

Als 4D en PowerGrade nou gewoon al een universal binary waren geweest...

[polthemol]

als ik naar mijn bankrekening kijk hebben ze bij de rabobank volgens mij ook apples draaien ;P Definitief zeker fout afgerond.

Lullige fout wel en raar dat ze dat niet opmerken met bugtesten ? Lijkt me toch een redelijk essentieel onderdeel van een os: rekenen.

[Maurits van Baerle]

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"

[Wouter Tinus]

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.

[Japs]

Wanneer een processor met floating point getallen rekent slaat hij ze nu eenmaal op in de vorm van x*10^y

floating point wordt opgeslagen als:
x*2^y
waarbij x en y een vast aantal bits hebben.

Om een idee te krijgen (6-bits Floating Point):
110E111 (binair)
zou zijn (1*1+1*0.5+0*0.25)*2^( - (1*2+1*1))=1.5*2^-3=0.1875
(de 1e bit achter de E geeft het teken aan (1->negatief,0 positief)

[Phoenix_X]

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.

[schoene]

dat is omdat
1)een getal binair wordt opgeslaan
2)een getal niet met oneindige precisie wordt opgeslaan
(0.2 heeft in het binair talstelsel een oneindig aantal cijfers na de komma)

[url="http://"http://docs.sun.com/source/806-3568/ncg_goldberg.html""]What Every Computer Scientist Should Know About Floating-Point Arithmetic[/url]

[Anoniem: 190996]

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.

[schoene]

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.

[catfish]

[dubbel]

[MisterICE]

De afrond functie in mijn Excel 2002 doet het (raar genoeg?) wel goed
=AFRONDEN(A1*6-1,5)

[Anoniem: 78237]

Uhuh. Dit is exact wat er gebeurd bij het gebruik met floating point nummers. Het is doorgaans een goed idee om, indien mogelijk, nummers te gebruiken die op een exacte (BCD of java's BigDecimal etc) manier worden opgeslaan. Deze hebben dan wel meer tijd nodig om berekeningen op uit te voeren, maar ze zullen tenminste niet beweren dat "=A98*6-1" gelijk is aan 5,37E+059 .

[4VAlien]

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

[Anoniem: 72316]

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


.................

[Anoniem: 179284]

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)

[Onno]

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?

[kimborntobewild]

@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

[Twixie]

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.

[Anoniem: 42145]

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.

[Anoniem: 133254]

'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.

[Vaan Banaan]

_{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.

[zalazar]

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.

[kamerplant]

@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).

[Frank-L]

@Datafeest:
Calc simuleert gewoon een goedkope calculator. Zoeen zonder sin/cos/tan en zo. En die houden normaalgesproken ook geen rekening met MVDWOA.

[kamerplant]

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.

[Dysmael]

@Frank-L:

Wat doen die knoppen:
SIN, COS en TAN dan bij mij in calc.exe? ;-)

[Frank-L]

We hadden het toch over de niet-scientific mode van calc?

[XiQ]

Mooi voorbeeld inderdaad.

Als je precieser wil zien wanneer het fout gaat: in excel (en in openoffice etc) kan je het aantal cijfers achter de komma instellen, met 10 cijfers zie je het bij 9e berekening fout gaan...

[frankvdtillaart]

Edit: Verkeerd gelezen (dus hier stond onzin), nog eens ingevoert, nu snap ik je punt. Leuk voorbeeld!

[DieterVDW]

Dit werkt toch wel gewoon zoals het moet bij mij hoor...

[Anoniem: 133254]

Ik neem aan dat je de regel "copy this to about A40" gemist hebt?

[Dukey]

Ik heb jouw test net uitgevoerd en ik krijg in A3 tot A40 gewoon netjes 0,2 (Excel 2003 SP2)?

0.2 van jouw voorbeeld krijg ik natuurlijk een formule fout op omdat de punt geen getal weergeeft.

[Anoniem: 53573]

Ik hebje testje op OpenOffice 2.0 en MS Office 2003 getest en bij geen van beide krijg ik vreemd gedrag. Gewoon overal 0,2 als uitkomst.

edit:
meer als 10 velden kiezen, dan gata het hardstikke fout :-) Grappig!

[Parasietje]

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)

[Maurits van Baerle]

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?

[kimborntobewild]

@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.

[Anoniem: 164083]

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...

[TommyboyNL]

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.

[magel725]

Misschien hebben ze i.p.v. een Dual Core processor er per ongeluk een eerste generatie Pentium in gezet?

[ebes]

Hoe ging die ook al weer?

"We are Intel. Resistance is futile. You will be approximated"

[Little Penguin]

Afrondingfouten in versie 10.4.85461?

Overigens lees ik dat de bug in Rosetta (de PPC emulatie) zit en het strikt genomen dus geen bug in het OS zelf is....

[itarix]

is rosetta dan niet onlosmakelijk verbonden met het os?

[Little Penguin]

Voor PowerPC computers: Nee.

Voor Intel Macs: Ja, maar alleen gebruikt wanneer er PowerPC binaries uitgevoerd moeten worden. Native intel binaries hebben dus geen last van dit probleem...

[Maurits van Baerle]

Nee, iTunes is een Universal Binary dus draait native op Intel.

[mieJas]

Dacht dat iTunes ook Rosetta nodig had...

[Carbon]

Dacht dat iTunes ook Rosetta nodig had...

Nee, iTunes is een universal binary.

[Ramzzz]

Dat was toch ook met de opvolger van de 486? De 585,999999, alias de Pentium?

[trogdor]

Nee, daar zat een hardware fout in de floatingpoint unit. Hier betreft het een software fout in Rosetta, wat emulatie software is.

[Anoniem: 174951]

Toevallig vorige week al een update moeten installeren vanwege het probleem met 4D, heb er verder niets van gemerkt en niets over gehoord van de mensen die hier intensief mee werken!

Wel goeie zaak dat het probleem in ieder geval "gepleisterd" is... alhoewel ik bij het maken van offertes, de afronding achter de komma toch maar marginaal vindt, is het toch beter te weten dat dit verholpen is. Wel slechte zaak dat dit soort problemen op het niveau van Rosetta ligt. In mijn beleving wederom een negatief puntje van de Intel Macs, waar ik vergeleken met de Power PC processors nog niet geheel tevreden mee ben. (defecte Macbook Pro, standaard te weinig geheugen in MacBook & Mini's)

[Anoniem: 71430]

En hoe zit het nu met de berekeningen die gedaan zijn, voor deze patch?

Ga je die nu overnieuw doen? Omdat je nu weet dat er fouten in kunnen zitten?

[Anoniem: 48534]

Ik vind iedereen nogal lauw reageren.

Ik vind dat Apple zich hiermee ernstig in de vingers snijd. Immers, veel laboratoria en onderzoekscentra zijn de afgelopen jaren overgestapt op Mac OS X. Die zitten niet op dit soort onbetrouwbaarheden te wachten.

Als ook toch wel erg "gewone" gebruikers als docenten tegen rekenfouten aanlopen dan lijkt het me gepast dat Apple onmiddellijk 10.4.8 terugtrekt en zo snel mogelijk met een nieuwe versie komt.

Ik mis hier echt een pro-actieve houding van Apple.

En nee, ik ben geen MS of Linux-fanboy, heb al een mac sinds de SE/30.

[martijnvanegdom]

Let goed!.. Het gaat om de intel mac met daarop powerpc programma's (deze worden dus door rosita gedraaid)

Als jij je als lab serieus neemt en je kies voor preformance dat houd je je gewoon bij je powerpc mac als je powerpc programma's gebruikt en wacht je tot er intel programma's komen.

Ja dit is een enorm slordige fout. Waarschijnlijk word er iets verkeerd gegooid in de emulaotr. Maar ik denk dat het uiteindelijke problemen redelijk meevalt

[increddibelly]

waarschijnlijk word er iets verkeerd gegooid in de emulaotr

rofl @ typo

[Maurits van Baerle]

Als ook toch wel erg "gewone" gebruikers als docenten tegen rekenfouten aanlopen dan lijkt het me gepast dat Apple onmiddellijk 10.4.8 terugtrekt en zo snel mogelijk met een nieuwe versie komt.

Dat is toch ook precies wat ze doen?

Apple heeft het probleem onderkend en werkt aan een patch om de nauwkeurigheid van OS X in ere te herstellen. Vooralsnog is er echter geen officiële oplossing beschikbaar, waardoor in het geval van de leraren wordt geadviseerd om de 10.4.8-update niet te installeren of zelfs te verwijderen.

Verwacht binnen een paar dagen een patch...

Bovendien is een veelgebruikte professioneel/wetenschappelijke toepassing als Mathematica gewoon een Universal Binary en heeft er dus geen last van.

[stewie]

non-sense, ze brengen gewoon een patch uit.

[PeterSelie]

Hierbij komt maar weer eens sterk aan het licht hoezeer we tegenwoordig van computers afhankelijk zijn.

Vaak wordt er hierdoor vanuit gegaan dat computers alles in perfectie kunnen afronden (met de andere betekenis van het woordt dan in het artikel ) en wordt er vaak geen rekening gehouden met het feit dat de verantwoordelijkheid uiteindelijk ligt bij de mens: de ontwikkelaar van de soft- / hardware.

[rlKoekie]

das lullig, zakken omdat je docent een mac heeft

[killercow]

tjah,

Ik denk dat het andserom veel vaker bijna mis is gegaan:
zakken omdat je docent een windows bak heeft, en of:
A: jouw oasis document niet wil openen.
B: communicatie met hem verloren gaat in de spam gevoelige outlook express
C: d jouw documenten en communicatie kwijt is geraakt aan een virus probleempje.
D: gewoonweg niet begrijpt dat bron materiaal in Excel met 1001 marco's en vb meuk niet universeel te lezen valt.

Toen ik naar de basischool gind waren er nog protesten tegen leraren die een lager cijfer gaven als een werkstuk handgeschreven was. De leraar vondt dit minder verzorgt, de ouders vonden het onzin om een computer aan te schaffen zodat het werktstuk uitgetikt kon worden.

Nu 10 jaar later wordt er door leraren en scholen zelfs bevoordeeld op het gebruik van software van een monopolist.

[souderkeamer]

Als hier maar geen rechtzaak van komt aangezien dit dus hele belangerijke kunnen zijn.
^{Als de creditcard bedragen hier misschien mee afgerond worden.. tja}