nicht angemeldet
Hallo axel!
Auch hier dient das binäre Zahlensystem nur als Erklärung, warum das passiert. Die Lösung, die dort "Korrektur" genannt wird, basiert aber leider auch nur auf "modifiziertem" Runden (statt runden, Zahl um 0.1 erhöht und Nachkommastellen abgeschnitten) in der Form wie ich es in meinem ersten posting beschrieben habe...
Wenn du nicht um 0,1 erhöhst sondern die Zahl mit 10^(Zahl der Nachkommastellen +1) malnimmst, dann 5 addierst, dann die letze Stelle per Stringoperation abschneidest und dann per Stringoperationen das Dezimalkomma an die richtige Stelle einfügst, dann rundest du richtig. (Und im Gegensatz zu den round(..)/100 Lösungen auch ohne das der Fehler bei ungünstigen Zahlen wieder reinkommt.) [2]
Bei Zahlen in Exponentialdarstellung wirds aufwändig.
Alles in allem scheint es keine (für mich) befriedigenden Ergebnisse zum Thema Zahlen in Javascript zu geben. Ich stelle mir nur den Fall von etwas aufwendigeren Berechnungen vor, wo sich solche Fließkommafehler ja durchaus "hochschaukeln" können oder wo ergebnisabhängig verzweigt wird (if x<=1.1 s.o.) und das dann falsch! Man kann ja auch nicht nach jedem Rechenschritt runden, da man sich dann entweder in den Nachkommastellen oder in der Zahlengröße sehr stark einschränken muß.
Das ist kein Javascript-Problem. Um das zu untermauern müsste ich dir jetzt aber doch erklären wie das mit der Zahlenrepresäntation im Rechner so ist.
Ein Minibeispiel kann ich mir aber nicht verkneifen:
Rechne mal ((1E10 + 1E-10)-1E10)*1E10) mit einem System deiner Wahl aus. Es wird Null rauskommen und nicht Eins.
Bei aufwändigeren Berechnungen mit begrenzter Stellenzahl[1] kommt man um eine Fehleranaylyse nicht drumrum.
Wieso muß ich eigentlich immer wieder lesen (nicht nur hier im Forum), daß Javascript da gar keinen Fehler macht,
Die Aussage lautet: es ist kein JavaScript-Rechen-Fehler, denn dannach wird i.a gefragt.
Natürlich ist die ungerundetet Ausgabe (und das Fehlen formatierender Ausgabefunktionen) ein schwerwiegender Entwurfsfehler von Javascript.
.... Turbo-Pascal-Compiler ist doch wohl um das binäre Zahlensystem letztendlich auch nicht herumgekommen (oder?). Trotzdem konnte man damit vernünfig rechnen.
Binär ja, Vernünftig ja, auf jeden Fall richtig:nein.
Die Turbo-Pascal Programmierer hatten nur mehr Durchblick was Anwendung ihrer Ausgaberoutine für praktische Aufgaben angeht. Die rundet nämlich auf soviele Stellen, wie meistens noch sinnvoll sind.
Vielleich komme ich auf Deinen ersten Vorschlag zurück, Ed X, und werde mich mal mit Java beschäftigen, obwohl ich das zum einen unbefriedigend finde und mir zum anderen nicht sicher bin, ob das Ergebnis bessr ist (siehe http://www.teamone.de/selfhtml/sfarchiv/2000_3/t17812.htm).
Keine Programmiersprache [1] wird da grundsätzlich besser sein - es gibt nur welche, die Funktionen zur Ausgabeformatierung besitzen (ähm...eigentlich ist Javasript die einzige (höhere) die keine hat).
Gruss,
Carsten
[1] beim PC werden die Berechnungen typischerweise von der CPU selbst gemacht und die verarbeitet 80 bit Mantisse, egal von welchem Programm sie benutzt wird.
[2] Wichtig ist niemals durch 10 zu teilen, da 0.1 ein unendlicher Binärbruch ist, der weitere Rechenfehler einführt.