Ich hatte in Ruhe gelesen
Nun zitiere ich dich:
dann muss das Ergebnis korrekt auf die darstellbare Genauigkeit hin gerundet sein
Was soll DAS denn? "Korrekt" ist ja wohl mit mehreren verschiedenen Möglichkeiten einer Rundung schlecht machbar, oder nicht?!
Und die Anzahl der Stellen ist dabei belanglos, denn das definiere ich ja in meinen Anforderungen.
Das Problem ist, und das kommt in diesen Beiträgen keineswegs rüber, nicht die Berechnung an sich, sondern die Darstellung der Nachkommazahl.
Und die hat wiederum mit der Genauigkeit der Berechnung nichts zu tun!
Beispielsweise rechnet die "alte" FPU in x86-Prozessoren mit 80 Bit Genauigkeit. Dargestellt werden idR Zahlen (nach IEE 754) mit 64 Bit. Man könnte jetzt meinen, egal nach welchem Verfahren gerundet wird, das Ergebnis ist immer "richtig", da der letzte Teil der Nachkommastellen, die 16 Bit Differenz, sowieso abgeschnitten wird. Für eine einmalige Addition/Multiplikation ist das auch wahr, egal welchen Rundungsmodus ich im Prozessor einstelle.
Also wo liegt das Problem? Das Problem liegt in der Berechnung innerhalb langer Schleifen, in der dieser "Fehler" in jeder Berechnung mitgeschleppt wird. Irgendwann dringt der Fehler in den Bereich der Darstellung vor, wobei die Anzahl der dargestellten Nachkommastellen dabei irrelevant ist.
Konkreter: Rechenergebnis mit 10 Stellen wäre: 0,1234567890 - dann muss diese Zahl folgendermaßen auf 5 Stellen abgebildet werden: 0,12346 anstatt einfach nur 0,12345 hinzuschreiben
Soweit richtig. Was dabei aber vergessen wird, ist denn die Berechnung (NICHT die Darstellung!) des Ergebnisses, also in diesem Fall die "Zahl" 0,1234567890 überhaupt "richtig"? Denn je nach Rundungsmodus/Einstellung Prozessor weicht das Ergebnis nach einigen Millionen Iterationen um Faktor X ab. Wenn jetzt nach diesen einigen Millionen Iterationen das Ergebnis bspw. 0,2345678901 lautet, dann ist es völlig unerheblich, ob diese Zahl dann "korrekt" auf 5 Stellen gerundet wurde.
und durch entsprechende Standardisierung auch einheitlich.
So muss das auch sein, aber wieso sieht die IEEE dann explizit 3 Rundungsmodi vor? Um doch genau die Freiheit zu geben, diesen "Fehler" (im System) geradezubiegen. Und zwar so, dass das Ergebnis zur Berechnung "passt".
Das eigentliche Problem ist systemimmanent bei Berechnungen im Binärsystem. "Flippe" ich das letzte Bit der Berechnung oder nicht? Halbe Bits gibt es keine....
Die von dir angesprochene "Standardisierung" sagt
Zitat
Statistisch wird dabei in 50 % der Fälle auf-, in den anderen 50 % der Fälle abgerundet,
aber laut der Anwendung dieser Statistik haben ein Millionär und ein armes Schwein jeder eine halbe Million!
Wenn die Raumfähre den Landeplatz auf dem Mars verfehlt, weil Europäer und Amerikaner unterschiedliche Maßsysteme verwenden, dann kann man darüber grinsen, aber wenn das passiert, weil bei der Auswahl des "Rundungsmodus" statt "Richtig" einfach nur "Standard" (in diesem Falle FALSCH, denn das Ziel wurde verfehlt) gesetzt wurde, dann werde ich nachdenklich.
Es kam schon öfter vor, dass ich diverse Algorithmen in ASM umgesetzt hatte und meine Ergebnisse (mit Standard-Einstellung) von denen diverser Compiler/Prozessoren abwichen. Bei der Analyse des Sourcecodes/Compilereinstellungen stellte ich dann fest, dass die Programmierer sehr wohl die unterschiedlichen Möglichkeiten bspw. beim Runden nutzen (in den Prozessoreinstellungen!) , um das Ergebnis an ihre Erwartungen anzupassen.
Bei Crosscompilern ist das auch bitter nötig, und wenn das nicht funktioniert, na dann wird eben ein "Emulator" benutzt, der die Berechnungen aka Ergebnisse "richtig" anpasst.
Um bei der Landefähre zu bleiben: Wird der Landeplatz auf dem Mars erreicht, weil bei der Berechnung alles "richtig" berechnet wurde, dann heißt das noch lange nicht, dass dieses System mit identischen Berechnungen zielgenau auf dem Jupiter (oder einem seiner Monde :o) ) landen würde....
"Standardisiert" ist immer nur so gut wie das damit erreichte Ergebnis.
...war mir auch aufgefallen, nachdem ich den Post abgeschickt hatte 