Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 96 reacties
Bron: Infoworld, submitter: mrtnvnl

Bij Infoworld is een artikel verschenen over een team onderzoekers van Sun Microsystems dat werkt aan een oplossing voor onnauwkeurige berekeningen. Hun werk is onderdeel van een project van het Amerikaanse leger. Aanleiding voor het onderzoek is een incident in de Golfoorlog van 1991, waarbij Patriotraketten een Scud-aanval niet konden tegenhouden. De Scud-raket raakte zijn doel, een Amerikaanse kazerne in Saudi-ArabiŽ, en 28 soldaten vonden de dood. Een jaar later was de conclusie dat het systeem dat de Patriots bestuurde niet nauwkeurig genoeg kon rekenen en dat hierdoor fouten ontstonden.

SunVolgens Greg Papadopoulos van Sun realiseren mensen zich niet dat computers vaak rekenfouten maken, waardoor ze bijvoorbeeld ineens vastlopen. Oneindige getallen kunnen binnen een computer niet precies gerepresenteerd worden, er zal op een bepaald aantal cijfers achter de komma moeten worden afgerond. De onnauwkeurigheid wordt meegenomen in volgende berekeningen en zal daardoor steeds groter worden. In het geval van de Patriots zat de fout in de berekening van de tijd. Door afrondingen tijdens de calculaties kreeg de berekende tijd per uur een afwijking van 0,0034 seconden. Toen de Scuds afgeweerd moesten worden, was het systeem al honderd uur operationeel en was er inmiddels een afwijking van een derde seconde. De Patriots misten hierdoor de Scud-raket.

De onderzoekers van Sun bekijken nu een oplossing die werkt met een techniek genaamd interval arithmetic. Een getal wordt hierbij gerepresenteerd door een interval waarbinnen het zich zeker bevindt. Het krijgt een onder- en bovengrens die wel nauwkeurig zijn. Op dit moment wordt de techniek al ondersteund door een aantal compilers. Sun werkt nu aan het versnellen van operaties met intervallen om een zo goed mogelijke performance te krijgen. Interval arithmetic zal gebruikt worden in Suns supercomputer Hero die twee biljard instructies per seconde moet gaan uitvoeren.

Moderatie-faq Wijzig weergave

Reacties (96)

Het gaat dus niet om hele getallen (integers) maar om complexe getallen (floating point).

Het probleem is dat je ook bijvoorbeeld de wortel van 2 niet precies kunt uitrekenen. Daarom blijf je op een bepaald aantal cijfers achter de komma steken. De significantie is dan dus niet hoog genoeg, en met computers kun je geen 'berekening laten staan'; je kunt niet zeggen dat het antwoord de wortel van 2 is en dat hij daar dan (bijvoorbeeld) een kwadraat van moet nemen (dan krijg je dus weer 2).
Als de significantie dan niet hoog genoeg is, kan het antwoord uiteindelijk op iets anders dan 2 uitkomen. En daar is het probleem.
je kunt niet zeggen dat het antwoord de wortel van 2 is en dat hij daar dan (bijvoorbeeld) een kwadraat van moet nemen (dan krijg je dus weer 2)
Dat kan wel, denk aan de functionaliteit van matlab. Over het algemeen heb je natuurlijk wel gelijk, en daarom moet je als informaticus bij dergelijke systemen daar ook rekening mee houden. Het is al lang mogelijk om met relatief eenvoudige wiskunde aan te geven wat de nauwkeurigheid is van de uitkomsten. Als je je van dergelijke problemen bewust bent, dan zijn de problemen te voorkomen.

De problematiek is al lang bekend en wordt ook onderwezen tijdens studies informatica: Computational Science: de wetenschap van het berekenen van dingen. Een ander (groter?) gevaar is de keuze voor een numeriek instabiel algoritme. Door het juiste algoritme te kiezen kan de invloed van afrondingsfouten worden verminderd.

edit: als reactie op jouw reactie: Ik was even vergeten te zeggen dat je over het algemeen inderdaad wel gelijk hebt, maar dat het wel mogelijk is exact te werken of nu al met de afrondingsfouten rekening te houden, door bijvoorbeeld een ander algoritme te kiezen.
edit: als reactie op jouw reactie: Ik was even vergeten te zeggen dat je over het algemeen inderdaad wel gelijk hebt, maar dat het wel mogelijk is exact te werken of nu al met de afrondingsfouten rekening te houden, door bijvoorbeeld een ander algoritme te kiezen.
Het is dus niet altijd mogelijk om exact te rekenen. In bepaalde gevallen wel, maar dat is niet altijd.
Ja dat zeg ik toch?
Mijn punt is juist dat het (soms) wel mogelijk is door symbolisch te rekenen of door een beter algoritme te kiezen de gevolgen van afrondingsfouten te minimaliseren zijn.
Daar heb je gelijk in.

Het kost een computer alleen erg veel moeite om de 'patronen' in algebra te herkennen, waardoor ze langzamer zouden werken (nouja... Een rekenclustertje zou veel goedmaken, maar dat is lang niet voor alle projecten inzetbaar).
En je bent dan dus niet met rekenen bezig, maar met het oplossen van algebraÔsche problemen. En dat kost dus erg veel processorkracht meer, omdat je per 'vereenvoudigingsstap' een kwadratisch aantal mogelijkheden creŽert.
Complexe getallen zijn weer wat anders, het gaat om reeele getallen.
Het is een feit dat je met floating point zeer grote tot zeer kleine getallen kan weergeven, maar dat ze ook (zeer) onnauwkeurig zijn. Als je hiermee dan zware berekeningen doet is het geen wonder dat er fouten optreden, die in sommige gevallen een slechte afloop kennen.
De afwijking van het getal is nooit zeer onnauwkeurig. Sterker, de grote van de maximale afwijking is altijd bekend en erg klein. Problemen bestaan pas als er gerekend wordt, voorals als dit verkeerd gaat.

Een voorbeeld. Ik ga uit van een (lage) precisie van 4 getallen achter de komma.
het getal x=0.0001 is best precies weer te geven (namelijk ongeveer als 1.0000 * 10-4)
het getal y=10000 ook (1.0000 * 10+4)
maar in de berekening van ((x+y)*y)-(y*y) gaat het ongelofelijk fout.
symbolisch gezien is dit namelijk gewoon gelijk aan
x*y + y*y - y*y = x*y = 1.0000
maar nummeriek berekent krijg je:
x*y = 10000 + 0.0001 = 10000.0001 (afgerond op 4 significante cijfers, de maximale precisie) = 10000.
10000 * 10000 - 10000 * 10000 = 0.0000;
dus ondanks het feit dat alle input 4 significante cijfers had, heeft het resultaat geen significante cijfers meer!
Waarom word de afwijking evenredig groot met de tijd dat het systeem aanstaat?
Zodra er een raket gededecteerd word gaat hij toch berekenen hoe hij hem kan onderscheppen. Of het systeem al een uur draait of een jaar maakt dan toch niet uit?
Het is de parameter waarin de tijd staat die fout gaat. Hiervoor wordt klaarblijkelijk of een absolute tijd genomen en die wordt alleen tijdens "bootten" ingesteld of een tijdsverschil (bv lengte van een seconde) die alleen bij "bootten" wordt geijkt.
Als je dan niet tussendoor corrigeerd voor afwijkingen van de interne klok zullen deze op den duur uit de pas gaan lopen.

Voor synchronisatie met een atoomklok heb je een verbinding nodig. Al dan niet via sateliet. Ik kan me voorstellen dat je dat wilt vermijden, anders zal de tegenstander deze proberen te storen.
Ik geloof dat ik het nog niet snap.
Als het systeem de raket ziet dan bepaald hij de positie van de raket snelheid richting enz en aan de hand daar van de baan om hem te onderscheppen lijkt me.
Als de klok verkeert loopt mag dat toch geen invloed hebben. Stel dat de klok een jaar achterloopt. Hij ziet dan de raket op 12:00 uur 20 dec 2002 en berekend dat hij bv 18.32 sec later de raket moet onderscheppen. Hij wacht dan dus tot de klok op 12:00 uur en 18.32 sec 20 dec 2002 staat.
Waar kan de fout ontstaan?
Of zijn ze zo dom om voor het onderscheppen en meten verschillende klokken te gebruiken.
Waarschijnlijk worden de raketten aangestuurd door de militaire versie van de GPS. Ik kan me voorstellen de grotere nauwkeurigheid van de mititaire GPS variant gehaald wordt dmv betere klokken, dus indien geen rekening is gehouden de klok van tijd tot tijd te synchroniseren oid en er door gerekend wordt met de fouten kan ik me wel degelijk voorstellen dat het van belang is.

Laat ik er gelijk even bijzeggen dat ik niet geheel precies meer weet hoe GPS werkt (ik heb een hele tijd geleden daar een keer nagekeken), maar ik weet dat je uit de NMEA string van een GPS wel een tijd kan krijgen, hoe deze nu precies bepaald wordt weet ik niet.

Dus dit verhaal kan de plank geheel mis slaan, maar het geeft in ieder geval een indicatie dat de tijd een belangrijke rol kunnen spelen behalve 'time of impact' berekeningen, waar de absolute tijd inderdaad niet van belang is.
1. GPS is het militaire systeem van de VS.
Het mag ook gebruikt worden voor niet militaire doeleinden, maar met een factor 10 tot 100 mindere nauwkeurigheid.

2. De reden dat de patriot miste was omdat de interne klok van het lanceer mechanisme 0,333~ seconden achterliep op de werkelijke tijd.
Daardoor is de raket dus 0,333~ seconden te laat afgevuurd waardoor de scud's zijn gemist.

3. Een patriot is een redelijk domme raket, en het kan niet echt uit om deze slim te maken zolang het huidige systeem nog prima voldoet, en dus de lanceer mechanismes gebruikt worden zoals ze ontworpen zijn, mobiel! of iig de klok elke dag word gereset.
Kijk, ik neem aan dat je dit onderwerp niet echt kan googlen. :-). Maar ik stel me voor dat de computer zijn interne klok combineert met het radarscherm, en aan de hand van de tijd snelheid en positie berekent. (nu en wanneer de raket aan moet komen, die hebben immers een range)

Als het tijdselement in de computer niet zuiver is, dan kan de computer dus niet de goede koers uitzetten. Ik kan me voorstellen dat de duur van de uptime, de zuiverheid van de berekening van de tijd beÔnvloedt en de gevolgen van de afronding vergroot.

Overigens, ergens lijkt het me stug dat de patriot niet via satteliet zou willen synchroniseren met de klok. Immers, Amerikanen zijn vol op bezig met network centric warfare. Waarbij ze alles, maar dan ook alles van soldaat tot raket tot AWACS aan elkaar koppelen En waar ze iedereen van kok tot generaal de informatie voorschotelen die ze nodig hebben. (theater awareness heet dat)

Ik meen zelfs dat ik ergens las dat er een generaal was, die wilde dat elke militair iets van een 100mb verbinding met de centrale moest kunnen hebben. (hoe zat het ook alweer met breedband in de kleinere gemeentes in Nederland?)
Iets aangepast om de duidelijkheid te vergroten *hopelijk*
Misschien was de batterij gewoon bijna leeg :-) Dan gaat mijn horloge ook continue achterlopen. Geeft meteen een heel ander perspectief aan Seiko Kinetic -> charges your missile on impact.

Part, opmerking 1 waar, maar relevant?

Opmerking 2, waar, soort heldere samenvatting van wat ik hierboven uitgebreid bedoelde.

Opmerking 3, snap ik niet.
iig de klok iedere dag resetten
. Als de software goed ontwikkeld was en men had rekening gehouden met afronding, dan hadden ze het systeem ook zo kunnen maken dat het zichzelf resette (doet mijn Windows ook) danwel een signaal afgeven dat het gereset moest worden. (het lijkt me ook niet dat dat ding daarmee bezig moet zijn, als er een aanvalsdreiging is en dus dat je zelf het moment van een reset wilt kiezen (Bill Gates, lees je mee?))

Ik neem aan dat je met mobiel bedoelt, continue verbinding met een atoomklok oid.

Eigenlijk zeg je dan met het laatste argument toch net als de meeste anderen in deze topic, dat het systeem gewoon heel slecht ontworpen is. domme raket of niet, dit is allemaal heel makkelijk op te lossen met slim programmeerwerk.
Dit artikel suggereert dat het hier de computers zijn die fouten maken. Dat is niet de gehele strekking van het verhaal. Het gaat echter vaak om de programmeur. Numerieke wiskunde is een onzettend moeilijk vak. En als je onzorgvuldig programmeert kun je de gekste resultaten krijgen. Denk bijvoorbeeld aan oneindige reeksen. Als je niet heel secuur de volgorde waarin opgeteld/ vermenigvuldigd vastlegt danwel de manier waarop er afgerond moet worden, dan kun je werkelijk elk willekeurig antwoord er uit krijgen als je net de verkeerde combinatie van parameters meegeeft. Dat is de reden dat -1 +1 -1 +1 ...... -1/2 is terwijl +1 -1 +1 -1 ........... oneindig oplevert (pak me niet als het net andersom is of het minteken verkeerd). De computer heeft dan geen fout gemaakt. De programmeur ook niet, hij vertelt de computer tenslotte wat er moet gebeuren.Alleen vergeet hij dan de randvoorwaarden waarbinnen de berekeningen moeten worden uitgevoerd goed te definieren. Of nog erger, de randvoorwaarden zijn al verkeerd gedefinieerd in de microcode van een CPU.
Ik vind je voorbeeld een beetje raar, maar ik denk dat je zeker gelijk hebt dat dit de strekking van het verhaal is. Het is de programmeur die rekening moet houden met de numerieke instabiliteit van computers. Ik heb er zelf ook last van dat ik te snel aanneem dat dat 64-bits floating point getal er wel niet naast zal zitten.

Overigens zou een stukje hulp ondersteund door de compiler geen kwaad kunnen, want het is een erg vervelend proces om handmatig de numerieke instabiliteit uit te rekenen. Maar goed, misschien is het ook op te lossen met een klasse die berekeningen doet met floating points en tegelijk de afwijking bijhoudt, zodat je deze gewoon kan opvragen aan het eind van een berekening.
Interval wiskunde had hier niet gewerkt, en het verbaasd me nogal dat Sun dit toch voorstelt. Het enige wat er dan gebeurt was was dat je wist dat de berekeningen onnauwkeurig waren.

De oorzaak was het onterechte gebruik van floating-point getallen waar integers nodig waren. Beiden hebben maar een beperkt aantal bits beschikbaar. Als de getallen die je erin wil opslaan te groot worden verlies je dus een paar bits. Bij een integer vallen die bits aan de bovenkant weg; na 2^32-1 komt weer 0. Bij een floating point vallen die bits aan de onderkant weg: steeds minder getallen achter de komma, en op een gegeven ogenblik tel je met stappen van een paar miljoen - dat maak niet meer uit op een biljard.

Wat de programmeurs hadden gedaan was de systeemtijd als een floating point getal geprogrammeerd. Na 100 uur was er in die float nog maar een resolutie van ~0.3 seconden over. Op 100 uur is dat niet zo slecht. Het vervelende is alleen dat als je twee systeemtijden van elkaar aftrekt je een tijdsduur krijgt met dezelfde foutmarge. Als je dus een Patriot traject uitrekent van een minuut heb je daar ook een foutmarge van 0,3 sconden. Op een minuut is dat natuurlijk veschrikkelijk slecht.

Hadden de programmeurs integers gebruikt, met een constante resolutie van een milliseconde, dan hadden ze na 4 miljoen seconden = 1100 uur niet meer geweten dat ze al zo lang bezig waren, maar dan was de fout in tijdsduren ook gewoon 1 milliseconde geweest.

Wat Sun voorstelt had hetzelfde resultaat opgeleverd als de floating point versie, met het verschil dat al tijdens de lancering bekend was geweest dat de tijdsfout ergens in het interval [-0.3 , 0.3 ] lag. Waar in dat interval had je niet geweten.
Rekenen met intervals werkt eigenlijk heel simpel, bij elk getal worden een onder- en bovengrens opgeslagen. Voorbeeld met afronding op 2 decimalen:

neem de berekening 1.34 / 5 * 3

de computer berekend dit dan als:

(min:1.34, max: 1.34) / 5 = (min:0.26, max: 0.27) * 3
(min:0.26, max: 0.27) * 3 = (min:0.78, max: 0.81)

iets wat in c++ te implementeren is m.b.v. operator overloading.
Lijkt me voor wapens alleen geen optie. Want dit zou net zo goed kunnen betekenen dat de raket inslaat in Saddam's massavernietigingswapensuitvindcomplex of in het rode kruis ziekenhuis, dat ernaast staat.

Voor dit soort raketten geldt dat het raken van een andere raket eigenlijk verschrikkelijk moeilijk is. De patriot zal rond de mach 1 a 2 doen, de tegemoetkomende raket ook. Dan moet je wel heel scherp rekenen. Dan ontploft de patriot in de buurt van waar het moet en beschadigt raketten dusdanig dat ze niet meer functioneren. Die wolk 'scrapnell' heeft ook maar een beperkte omvang.

Wat betreft de berekening van jou. Wat gebeurt er al het door de mini en maxima onwaarschijnlijk wordt dat de raket iets gaat raken, gaat ie terug? De mini en maxima worden in principe ook alleen maar groter (in ieder geval relatief tov elkaar) dus in de vele duizenden berekening op weg naar zijn doel, zal ik me afvragen of afrondingsverschillen in de intervals dan niet weer een probleem worden.
Het betekent dat je voordat je de raket afvuurt al helder op je scherm ziet dat hij geen enkele garantie geeft dat hij niet het ziekenhuis pakt i.p.v. het doel. Dat lijkt me zťťr waardevolle informatie.

Dit voorstel betekent dat een computer voortaan zelf exact kan aangeven wat de significantie van z'n antwoord is en daarmee hoe waardevol het antwoord werkelijk is.
Oorspronkelijke reactie: "Meneer Van Dale Wacht Op Antwoord = Machtsverheffen,Vermenigvuldigen, Delen, Worteltrekken , Optellen , Aftrekken.

Jou som is dus = 1,34/15 = 0,089333333333333333333333333333333

En dus niet (1,34/5)*3 = 0,804"

Maar:

Reactie op EvOlutionDesign: Je hebt gelijk, ik was niet op de hoogte van het overlijden van Meneer Van Dale.

Anders dan in de klassieke interpretatie van Meneer Van Dale is het tegenwoordig internationaal gebruikelijk om onderling inverse bewerkingen (machtsverheffen en worteltrekken, vermenigvuldigen en delen, optellen en aftrekken) als gelijkwaardig te beschouwen en van links naar rechts uit te voeren. Curieus is in het bijzonder de prioriteit van het worteltrekken volgens Van Dale.
Een ezelsbruggetje voor een iets meer volledige regel voor het wiskundeonderwijs op de middelbare school die past bij de moderne conventies op het gebied van notatie, luidt:

Hoe Moeten Wij Van De Onvoldoendes Afkomen.

Eerst de haakjes, dan machtsverheffen en worteltrekken (prioriteit van links naar rechts), dan vermenigvuldigen en delen (prioriteit van links naar rechts), en tenslotte optellen en aftrekken (prioriteit van links naar rechts).

Aldus in de wiskundebrief van de Ned.Ver.van Wiskunde leraren.

Met dank aan: P. Greydanus.


Zie ook:

http://www.wisfaq.nl/frame.htm?url=http://www.wisfaq.nl/overzicht.asp? categorie=Rekenen
Ehm... nee, vermenigvuldigen staat gelijk in de reeks met delen, net zoals op / aftrekken. Dus wel degelijk (1.34 / 5) * 3.

Over Van Dale gesproken: vermenigvuldigen. :Y)
Het gaat volgens mij hier eerder door rekenfouten die ontstaan door invloeden van buiten af.

De computer houdt hier geen rekening mee en maakt hierdoor ook missers.
Dus je wil zeggen dat jouw "gut" feeling zegt dat wat Sun, een team van onderzoekers en een research budget van meerdere jaarsalarissen niet klopt en jouw ongefundeerde mening wel.

Wellicht handig als je daarbij ook even een paar argumenten geeft waarom je denkt dat wel gelijk te hebben.
Wat hij bedoelt is dat EM straling (al dan niet menselijk van oorsprong) een aantoonbaar effect heeft op computers. Zeker met de steeds groter wordende kloksnelheden gaat het quantum effect van rondvliegende elektronen een steeds grotere (storende) rol spelen.
Ik poste mijn bericht voordat het stuk erop stond dat het hier om afrondingen gaat.

En de mening van iemand is dus niks waard als deze niet gefinancierd wordt door een of andere grote liefdadigheidsinstelling als een overheid :?
Nee, het gaat om getallen die worden afgerond en afgerond en afgerond en afgerond en die bij afgronde getallen worden opgeteld en afgetrokken, vermenigvuldigt en gedeeld waardoor je na verloop van tijd met een (te) grote onnauwkeurigheid zit.
Computers rekenen.

Computers kunnen alleen maar rekenen. (tellen / vergelijken)

Computers rekenen niet goed of slecht.

Goed of slecht is een subjectief begrip.

Wanneer een computer niet het gewenste resultaat geeft aan de hand van een aantal vergelijkingen wordt dit ervaren als slecht / onjuist.

Aanpassingen in software kunnen dit voorkomen.
[grof]
Je praat poep.
[/grof]

Computers rekenen fout. Ze zijn niet nauwkeurig genoeg, en dat is op een examen, of in het echte leven, toch ťcht fout.

Als iets fout is, is het slecht.
Voor een computer is 1 -> 1 en 0 -> 0

Dit is een 1 op 1 interpretatie, in tegenstelling tot 1 op veel interpretaties(meedere interpretaties mogelijk van een symbool/situatie/toestand)

Als een computer niet nauwkeurig genoeg is zijn het aantal vergelijkingen die de software laat doen voordat de uitslag wordt gegeven, te laag. Er moeten dus meer interaties(herhalingen van vergelijkingen) plaats vinden , in feite, wat dus tot een nauwkeuriger resultaat leidt. Dit is softwarematig te realiseren.

Omdat erbij dit soort toepassingen zoals scud-aanvallen een tijdsdruk is, is het aantal iteraties/vergelijkingen beperkt en dus neemt de onnauwkeurigheid toe.

Een 8 bits processor kan precies het zelfde als een 64 bits processor, alleen binnen een ander tijdsbestek.

Je zal dus voor een scud-aanval eerder een 4Kbit processor nemen dan een 8bits processor.

ps. Computers kunnen wel fouten maken in de zin van processor-ontwerp fouten(eratta).
Ik ben het volledig eens met wat Chippey zegt. Als de software die de patriot raketten aanstuurd afhankelijk is van de tijd die het systeem reeds aanstaat dan is deze incorrect. Dit staat volledig los van de gebruikte computers.

Een computer kan niet rekenen met oneindige getallen ... Ik zou wel eens willen weten wie wel ;)
Computers rekenen fout.
Dat is niet waar. Ze doen precies wat jij verteld dat ze moeten doen.
Als jij een benadering doorvoerd (operatie zonder verlies van nauwkeurigheid vervangt door een operatie met verlies) als je vertelt wat ze moeten doen en daar later geen rekening mee houdt, is dat toch echt je eigen schuld.
ikke,
en alle software die met symbolische algebra overweg kan ook, zoals matlab, mathematica, mupad enz...

Misschien moeten we toch weer eens wat wiskunde onderwijs invoeren ?
Nee de problemen die ze hier proberen aan te pakken worden veroorzaakt door onnauwkeurigheid van de getallen waarmee gerekend wordt.

Doe op je rekenmachine maar eens:
10^-50 (=0,0000 ... 0001)
+ 1
- 1
=
en er komt geen 10^-50 meer uit. (tenzij je rekenmachine deze stappen optimaliseert, sommige duurdere rekenmachines kunnen dat)
10 ^ 50 = 10 ^ 50 + 1 = 10 ^ 50 + 1 - 1

Als je de exponenten van 10 ^ 50 en 1 synchroniseert, wordt 1 namelijk 0 (als we het over 32- en 64-bits floating points operaties hebben natuurlijk).
hey olaf, effe goed lezen. er staat 10^ - 50 en dat is een erg klein getal.

Verder is de strekking van je commentaar goed, want als je 10 ^ - 50 uitzet in 32 bits is dit nul. Daar 1 bij optellen en dan weer er af trekken is...... you guess
Sorry, had de min niet gezien.
32-bits floating points gaan verder dan 10 ^ -50 volgens mij, dus het wordt geen 0. Pas als je er 1 bij optelt wordt het 0.
Ik snap je punt, maar wel grappig dat calc.exe hier geen moeite mee heeft..

edit:

Nauwkeuriger onderzoek heeft uitgewezen dat de onnauwkeurigheid in dit geval zit in de onnauwkeurigheid van de worstevingers van de stupid user behind keyboard.. Negeer dus a.u.b. deze opmerking
Heeft dit nu ook niet met de aansturing van de computer te maken? Is een ineffeciŽnte aansturing van het OS niet mede verantwoordelijk voor de onnauwkeurigheid en het zogenaamde "slecht" rekenen?
Nee, het probleem is dat als je dingen uitrekent dat je dat bijvoorbeeld in 32 of 64 bits getallen doet.

Die kunnen maar tot op een bepaald aantal decimalen nauwkeurig zijn.
Die patriots hadden gewoon beter geprogrammeerd moeten worden volgens mij, als programmeur weet je dat dat soort getallen worden afgerond. En in het stuk staat dat ze een compiler hebben gemaakt die dit probleem oplost, dus hadden ze die technologie ook bij dat Patriot systeem kunnen verzinnen. Ze hadden bijvoorbeeld een eigen datatype kunnen definieren die een onder en bovengrens bijhoud in plaats van af te ronden...
Het is altijd makkelijk om dat na dato te zeggen ;)

Het probleem van bugs is dat je vaak niet weet (of er niet aan denkt) dat iets, vaak triviaals, fout kan gaan.

En dan zit je uiteindelijk met gebakken peren ja.
Programming is the only art form that fights back
Hmm ja maar afronding is toch wel iets heel erg cruciaals waar je niet aan vergeet te denken (daar dacht ik namelijk ook aan toen ik laatst een uren-registratie programma in elkaar had gezet).

Wat ik trouwens ook vreemd vindt is dat het systeem zijn timing laat afhangen van een 100 uur oud getal.
Dat is niet raar: Je start het systeem op t=0. En t wordt met de tijd alleen maar groter. Na vier dagen heb je een afwijking van een derde seconde, en dat vind ik eerlijk gezegd nog erg weinig, maar helaas voor 28 soldaten toch nog teveel.

Nu zou je het systeem kunnen resetten, zodat de waarde van t niet te groot wordt. Elke dag weer t=0 maken dus. De maximale afwijking zit dan binnen een tiende van een seconde. Eitje.

Maar wat nu als er juist een Scud onderweg is als het systeem gereset wordt? De Scud vertrekt op t=23:59:59 en een seconde later is t=0. Voor de computer is het dus weer het begin van de dag. De Scud die op de radar staat vertrekt over bijna 24 uur.
Op t=0 is hij minder ver weg dan op t=23:59:59 dus eigenlijk vliegt hij de andere kant op. Niks aan de hand...
Je kunt je natuurlijk afvragen waarom een raket iets zou moeten weten over 100 uur geleden, of over de tijd dat hij heeft staan wachten. Wat heeft zo'n systeem er aan te weten hoe laat het is? Het enige dat belangrijk is lijkt me de lokatie van de raketten en de snelheden e.d.

Maar even dom was dat op 1 januri 2000 een aantal stadsbussen de deuren niet meer wilde openen. Je vraagt je af wat een klok in de aansturing van de deuren doet.

Leraar: "Trein A vertrekt om 14:00 uit Breda en trein B vertrekt om 14:10 uit Eindhoven. Trein A rijdt 10km/u, trein B rijdt 120 km/u, Welke trein arriveert het eerst in Tilburg?"
Jantje: "hoe lang hebben de treinen staan wachten op de staions?"
Die dingen hebben toch een externe klok?
Tijd lijkt mij niet echt iets dat je gaat lopen berekenen door iedere CPU cycle 1 op te tellen bij de vorige ofzo want dan stapel je afwijking op afwijking.
Ze hebben die patriots dus gewoon slecht geprogrammeerd en hadden iedere minuut ofzo moeten synchroniseren met een externe (atoom)klok.
Dit hoeft natuurlijk niets te maken te hebben met de klok. Stel je het volgende probleem voor:

De software analyseert de baan van de scud en extrapoleert deze om te bepalen wanneer de raket op punt x zal zijn zodat een patriot goed getimed gelanceerd kan worden om de scud te onderscheppen.

Als er bij deze berekening fouten optreden door het gebrek aan significantie in de berekeningen zal een verkeerd tijdstip uitgekozen worden om de patriot te lanceren. Daardoor mist deze de scud.

Met het synchroniseren met een atoomklok doe je hier dus niets aan.
uit het artikel:
"Door afrondingen tijdens de calculaties kreeg de berekende tijd per uur een afwijking van 0,0034 seconden. Toen de Scuds afgeweerd moesten worden, was het systeem al honderd uur operationeel en was er inmiddels een afwijking van een derde seconde."

Ieder uur een afwijking x, (niet synchroniseren), na 100 uur een afwijking van 100 maal x.
Dit klinkt toch alsof het wel degelijk had kunnen worden voorkomen door die klok des noods een paar keer per dag te synchroniseren.
De computers rekenen niet slecht, de mensen die de computer programmeren laten de computers slecht rekenen ;)
Klopt helemaal. Wat dacht je van klimaatstudies waarbij clusters van computers geen dagen, maar weken operaties lopen uit te voeren op getallen? En die modellen die ze daarvoor gebruiken zitten numeriek nog viezer in elkaar ook. Ze moeten beter nadenken bij het implementeren van zo'n systeem.

En nog een ideetje: Test het eens in de praktijk voordat je er levens aan gaat ophangen. Dat scheelt ook weer. |:(
Bij klimaatmodellen is er goed over nagedacht hoor! Met weermodellen en klimaatmodellen worden meestal meerdere runs gemaakt, steeds met kleine veranderingen in de beginsituatie. De afwijking van de uitkomsten van de verschillende runs met verschillende beginsituaties zijn dan een maat voor de fout die in het specifieke model zit, door bijvoorbeeld afrondfouten en fouten door de keuze van de numerieke schema's. Zo wordt bijvoorbeeld op het ECMWF (=computercentrum waar ze een hoogresolutie weermodel draaien voor de middellange termijn), waar het KNMI zijn modelverwachtingen vandaan haalt, een ensembleverwachting gemaakt. Het KNMI zet daarvan de zogenaamde pluim op haar site: http://www.knmi.nl/exp/pluim/
Hiier kun je zien hoe de verschillende runs met verschillende begintoestanden, het weer voor de komende dagen voorspellen. Zoals je kunt zien lopen oplossingen soms erg uiteen, maar kun je toch wel enige trends eruit distilleren.

In principe komt het nog wel eens voor dat ze in het klimaatonderzoek een modelberekening publiceren, waarbij ze het maximale uit de computer hebben willen halen, dus maximale resolutie en maar tijd/geld voor 1 run. Als ze dan dus geen ensembleberekening doen, dan zijn de resultaten erg onbetrouwbaar. Hoewel iedereen dit zou moeten weten, gebeurt het toch nog wel eens binnen het weer/klimaatonderzoek...
Niet helemaal (helemaal niet)

Met kwantumcomputers zouden berekeningen met 'ongelimiteerde significantie' dichterbij moeten komen, maar het is nou eenmaal de complete architectuur (opbouw) van de computer waardoor het niet mogelijk is om een computer op deze manier te laten rekenen. Nu dus nog niet althans.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True