Chrissicom
Rise of the Ryzen
|
Hi, irgendwie kann Javascript nicht richtig rechnen....
Beispiel:
var foo = 4 * 77.27 und heraus kommt 309.0672 EUR var baz = 1 * 169.49 und heraus kommt 160.4939 EUR
wtf????
|
Nico
former person of interest
|
liegt ein hw-fehler vor?
script posten?
Bearbeitet von Nico am 19.05.2010, 22:34
|
Chrissicom
Rise of the Ryzen
|
K.a. ist nen Webpaket auf einem Fremden Server. Mit PHP rechnet er richtig.
Kann er durch eine sterbende CPU so einen Mist ausrechnen mit Javascript und PHP geht trotzdem? Die Fehler sind btw nicht zufällig, er kommt immer zu den selben falschen Ergebnissen.
Ich versteh vor allem nicht wie aus 1*X = X.foo werden kann.
|
SilentBob
Little Overclocker
|
|
Nico
former person of interest
|
thx, ist mir noch nie zu ohren gekommen
|
Chrissicom
Rise of the Ryzen
|
Ah cooler Link, werde das mit dem kaufmännischen Runden mal testen... obwohl ich das Math.round(n*100)/100 vorher schon probiert hatte und es zum gleichen Fehler geführt hat... allerdings ohne toString.... na ja mal testen, verzweifle an dem Käse grad  Cool, Danke, so funktionierts (ganzer Code): document.getElementById("myPrice").firstChild.nodeValue = roundRecommendation + " Pakete * " + kaufm(fullPrice) + " \u20ac pro Paket = " + kaufm(roundRecommendation*kaufm(fullPrice)) + " \u20ac"; kaufm(roundRecommendation*kaufm(fullPrice))... sieht etwas krüppelig aus, geht aber nur so. Die kaufm Methode hab ich einfach kopiert.
Bearbeitet von Chrissicom am 19.05.2010, 22:54
|
Mr. Zet
Vereinsmitgliedresident spacenerd
|
var baz = 1 * 169.49 und heraus kommt 160.4939 EUR
wtf???? Also DAS ist hoffentlich ein Tippfehler, das wäre doch ein recht dramatischer Rechenfehler
|
Nico
former person of interest
|
also mich hat er erschreckt
|
that
Hoffnungsloser Optimist
|
Also mein Browser rechnet da halbwegs korrekt, zumindest stimmen die Beispiele aus dem ersten Post. Welche JS-Implementierung kann bei dir da nicht korrekt mit 1 multiplizieren?
0.1 + 0.2 ist bei mir auch falsch, wie auf der von SilentBob referenzierten Seite - und ich glaube, das muss sogar sein, damit es standardkonform ist. Bei Excel übrigens genauso, nur zeigt das die Nachkommastellen normalerweise nicht an.
Bearbeitet von that am 20.05.2010, 00:40
|
prayerslayer
Oar. Mh.
|
|
Chrissicom
Rise of the Ryzen
|
Also ich erhalte in IE 8, Firefox 3.6 und dem neuesten Safari (den Windows Versionen dieser Programme natürlich, FF unter Linux kann durchaus was anderes machen) den genau gleichen Rechenfehler. Wenn es an der "Implementierung der JS Engine" liegt sind also alle gleich schlecht :P Ich meine wenn 0.1237682734*12376876*0.50 was falsches liefert ok... aber 1*169.49 wtf....  Das ist kein Tippfehler @Mr. Zet... macht Konqueror das denn richtig sofern er JS kann? Edit: Haha dieser Link kann einem ja jeglichen JS Spaß verderben  Edit 2: Jetzt seh ichs erst.... da kommt natürlich 169.x raus... aber er fügt eben 2 Nachkommastellen aus dem Nirvana hinzu, was bei 10*foo dann Probleme mit dem Ergebnis macht, weil das völlig falsch wird.
Bearbeitet von Chrissicom am 20.05.2010, 00:54
|
Ringding
Pilot
|
Die im Originalpost genannten Beispiele können aber nicht auf die bekannte Binär/Dezimal-Problematik zurückgeführt werden. Damit würde ein Fehler natürlich erst an der 7. Stelle (single precision) oder 15. Stelle (double precision) auftreten.
Mein Browser (Firefox 3.5.9 Mac OS X) liefert auch das erwartete Ergebnis.
Was ist das denn für ein Browser, der so einen Schmarren rechnet?
|
Ringding
Pilot
|
aber er fügt eben 2 Nachkommastellen aus dem Nirvana hinzu Das kann ich mir kaum vorstellen. Der Fehler kommt vermutlich von woanders, aber nicht von dem hier gezeigten Code.
|
Ringding
Pilot
|
Jetzt muss ich nochmal meinen Senf dazugeben. Das klassische Problem, das die meisten Leute verwirrt, und weswegen auch die hier verlinkten Seiten existieren, lässt sich in Python schön illustrieren:
>>> 4*77.27 309.07999999999998
Sieht vielleicht falsch aus, ist aber nur um einen Absolutwert von ca. 10^-14 daneben, also doch recht genau. Der relative Fehler ist erwartungsgemäß in der Gegend von 10^-16.
Wenn man z.B. auf 13 Nachkommastellen rundet, sieht man auch sehr schön, dass die Rechnung passt:
>>> "%.13g" % _ '309.08'
|
manalishi
tl;dr
|
Edit 2: Jetzt seh ichs erst.... da kommt natürlich 169.x raus... aber er fügt eben 2 Nachkommastellen aus dem Nirvana hinzu, was bei 10*foo dann Probleme mit dem Ergebnis macht, weil das völlig falsch wird. etwas mehr vertrauen bitte  ausm nirvana kommen die zwei dezimalen nachkommastellen eben genau nicht.
|