Fehlerhafte Darstellung von Zahlen

Hallo,

uns ist eben mehrfach das Problem aufgefallen, dass Knuddels offensichtlich nicht mit Zahlen umgehen kann.

James rechne 8-4.4
Ergebnis: 3.599999999999996

Auch wenn ich feste Dezimal-Werte in einer Persistence speicher und später wieder ausgebe erhalte ich solch krumme Zahlen, die einfach nur falsch sind.

Beispiel:
Gespeichert: 5.94
Ausgabe: 5.9399999999999995

Hallo,

danke für deine Meldung! Probier mal bitte die Ergebnisse aus 4-2.2, 16-8.8 und 9-5.4 in der Persistence zu speichern und schau mal, ob da auch krumme Werte rauskommen.

Grüße
Vampire183 (Bugs-Team)

1.7999999999999998
7.199999999999999
3.5999999999999996

Bei allen Werten die durch Subtraktion entstehen tritt dieses Problem auf. Nicht aber bei Addition, Multiplikation und Division, da gibt es dann korrekte Werte.

Auch interessant:

Maexxchen: james rechne 8-2.02

James: Um ganz exakt zu sein: 5.98.

Maexxchen: james rechne 8-2.03

James: Ich bin zwar kein Pythagoras, aber komme trotzdem auf exakt 5.970000000000001.

Maexxchen: james rechne 8-2.04

James: Wenn ich mich nicht irre, macht das genau 5.96.

Ich vermute, dass es da irgendein Problem mit der Zahlendarstellung intern gibt.

Das ist kein Bug als solches und das Verhalten ist normal. Arbeitet mit toFixed(dezimalstellen) wenn nötig.


Das Verhalten ist dadurch erklärbar, dass es nicht möglich ist alle Dezimalzahlen im Binärsystem darzustellen.
http://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/

Das ist nicht das gleiche. "Number.prototype.toFixed()" gibt einen String zurück, keine Number. Das ist eine Änderung im Verhalten.

Gemeint war erst die berechnung zu machen, dann toFixed nutzen und es ggf. wieder zu float parsen, um etwaige folgefehler zu begradigen

(toFixed rundet automatisch und gibt einen String wieder das ist klar) - Es geht da wohl eher um das das Einsatzgebiet ob man es am Ende als Number oder String braucht. Für eine reine Ausgabe reicht es toFixed zu machen.

Ich habs es ausprobiert, und es funktioniert tatsächlich (in meinem exemplarischen Beispiel). Das ist echt verwunderlich ... nichts desto trotz finde ich das keine praktikable Lösung.

Man muss in der Softwareentwicklung einfach damit leben, dass jede Sprache ihre eigene interne Darstellung von Fließkommazahlen verwendet, die unterschiedlich präzise sind. Für den alltäglichen Gebrauch von allen die hier unterwegs sind sollte das total ausreichen. Wirklich präzise Zahlensysteme braucht man z.B. im Bankensektor oder im wissenschaftlichen Bereich. :)

Ich finde es sehr schön, dass du sagst, wie App-Entwickler arbeiten sollen, das löst aber nicht das Problem der falschen Anzeige bei der Ausgabe von James. Denn die ist und bleibt falsch und damit ein Fehler, der notiert und weitergegeben wurde.

"Auch wenn ich feste Dezimal-Werte in einer Persistence speicher und später wieder ausgebe erhalte ich solch krumme Zahlen, die einfach nur falsch sind."

Ich bezog mich auf diesen Teil - Du als Bugsteamler auf den anderen (was auch vollkommen ok ist)
Ich ging davon aus, dass es dem TE vorrangig um die Appentwicklung ging (übrigens ist der Fehler seit mindestens 10 Jahren bekannt, den habe ich nämlich vor 10 Jahren bereits gemeldet)


@tobyb
Naja 0.1 ist aber nun nicht so eine exotische Zahl, dass man sagen müsste... Joa nicht wichtig.. Ich sag nur KnuddelAmounts

Übrigens hilft es, sich für den Schritt einen kleinen parseFloat mit in den toFixed reinzuprototypen




Ich stimme dir zu, dass es keine schöne Lösung ist, aber immerhin eine. Und 0.1 ist wirklich keine exotische Zahl und wenn man mit dieser Zahl rechnet und nicht irgendwie auf interger conversation oder eben rundung gehen will wird es für den Endnutzer eher suboptimal sein.

Huhu,

bitte sieh von derartigen Aussagen, wie schon des Öfteren diskutiert, ab. Du kennst die Regeln, bitte halte Dich zukünftig daran, danke. (Siehe Bugs-TL)

Wir haben das Problem natürlich schon "behoben", das war ja nicht die Schwierigkeit. Und ja, das Problem ist einfach die Zahlendarstellung. Wenn wir vom IEEE 754 - Standard ausgehen mit double precision, also 64 Bit, hat die Mantisse der Zahl genau 52 Bit. Mathematisch lässt sich damit der Rundungsfehler von 2^(-53) berechnen, was etwa 1,1*10^(-16) ist und somit den Fehler an der 16. Nachkommastelle erklärt. Allerdings kennt man diese Probleme als Informatiker eigentlich. Daher ist es schon verwunderlich, dass man bei den Ausgaben von James nicht darauf geachtet hat, dass eben dies nicht passiert. Denn hier wird sicherlich keine Genauigkeit von 16 Nachkommastellen benötigt. Das ist für den normalen Anwender nicht nötig. Übrigens geht hier auch das allseits bekannte Beispiel 0.1+0.2 schief. Es tritt also nicht nur bei der Subtraktion auf, wie vorher gesagt.