Java rechnet -0.94 + 0.01 falsch

[julchen81]

Hallo,

Wieso wird hier statt -0.93 der Wert 0.9299999999999999 ausgegeben? :noe:

public void testen() {
        double a = -0.94;
        double x = a + 0.01;
        System.out.println (x);
}

Bin gespannt und freu mich über eure Hilfe
Julchen

 

[Thallius]

Weil float und double nunmal nicht genau rechnen können.

Willst du ein exaktes ERgebnis must du mit integern rechnen

Gruß

Claus

 

[julchen81]

Danke schon mal!

Ich wusste, dass sie nicht genau rechnen können. Ich wusste aber nicht, dass das in diesem lächerlichen Bereich der Fall ist (nur 100stel genau und Berechsüberschreitung weit entfernt)

Mir bleibt also nichts anderes übrig, als z.B. hier zunächst sowohl a als auch x mit 100 zu multiplizieren (dann liegen int-Werte vor) und dann das Ergebnis wieder durch 100 zu teilen?!

Da ich obige Berechnung in eine for-Schleife mit mehreren 100 Durchgängen einbauen möchte (und jedesmal dabei eine Variablenwert um ein Hundertstel zunehmen soll), erscheint mir das sehr rechenaufwändig.

Gibt es keine idealere Lösung?

 

[Diabolus]

Weil float und double nunmal nicht genau rechnen können.

Bei mir funktioniert es mit float aber:

public void testen() {
        float a = (float) -0.94;
        float x = (float) ((float) a + 0.01);
        System.out.println (x);
}

 

[julchen81]

Bei mir funktioniert es mit float aber:

float funktioniert auch nicht, wenn ich die Rechnung in eine for-Schleife mit mehreren hundert Wiederholungen einbaue... :-(

 

[Thallius]

Warum bleibst du nicht einfach bei dem Wert * 100? Du must doch nicht jedesmal wieder durch 100 teilen

 

[nvidia]

Weil float und double nunmal nicht genau rechnen können.

Willst du ein exaktes ERgebnis must du mit integern rechnen

Gruß

Claus

Die rechnen schon genau, und zwar so genau wie es ihre Spezifikation vorsieht, der Fehler ist nicht zufällig. Um damit aber gut bzgl. numerischer Algorithmen umgehen zu können muss man schon tief in die Spezifikation von floats/doubles abtauchen. Ein kurzer Text ist What Every Computer Scientist Should Know About Floating-Point Arithmetic und wer sich die volle Packung geben möchte kann z.B. zum "Handbook of Floating-Point Arithmetic" greifen.

 

[julchen81]

Warum bleibst du nicht einfach bei dem Wert * 100? Du must doch nicht jedesmal wieder durch 100 teilen

Doch, muss ich, weil ich mit diesem Wert weiterrechnen muss. Mit dem 100-fachen weiterzurechnen passt nicht.

 

[Thallius]

Doch, muss ich, weil ich mit diesem Wert weiterrechnen muss. Mit dem 100-fachen weiterzurechnen passt nicht.

Glaube ich ehrlich gesagt nicht. Du kannst problemlos überall mit dem 100fachen rechnen one das Dadurch dein Ergebnis falsch wird.

 

[stg]

Du bringst da aber ein bisschen was durcheinander ... das Ergebnis ist nicht schon im "hundertsel" ungenau, sondern bis auf ein "10-Billiardenstel" (Abweichung vom echten Wert 0,000.000.000.000.000.1) genau. Also mir reicht in allen praktischen Anwendungen in aller Regel dann doch aus...

 

[Harry Kane]

Ich halte es für Quatsch, die Werte mit irgendwas zu multiplizieren/dividieren/Wasauchimmer.
ZUnächst mal muss geklärt werden, ob die Werte wirklich "ungenau" sind oder nur bei der Ausgabe komisch aussehen.
Im letzteren Fall kann die/der TE ruhig mit den Werten weiterrechnen und erst am Schluss das Ergebnis auf die gewünschte Anzahld er Nachkomastellen runden.

 

[Thallius]

Ich halte es für Quatsch, die Werte mit irgendwas zu multiplizieren/dividieren/Wasauchimmer.
ZUnächst mal muss geklärt werden, ob die Werte wirklich "ungenau" sind oder nur bei der Ausgabe komisch aussehen.
Im letzteren Fall kann die/der TE ruhig mit den Werten weiterrechnen und erst am Schluss das Ergebnis auf die gewünschte Anzahld er Nachkomastellen runden.

Warum so kompliziert. Wenn ich immer mit hundersteln rechne dann habe ich keine Rundungsfehler. Ich rechne grundsätzlich nur mit Fließkomma wenn ich große Zahlen brauche. Wenn ich weiß, dass meine Zahlen in einen Integer passen, dann benutze ich den auch, denn der ist nicht nur genauer, er ist auch um ein vielfaches schneller und speicher sparender.

Es gibt z.B. überhaupt keinen Grund Maße oder Währungen mit Fließkomma zu rechnen.

Gruß

Claus

 

[CSHW89]

Der Computer speichert halt im 2er-System. Damit können einige Werte mit Fließkommazahlen genau gespeichert werden, andere aber nicht. In unserem 10er-System ist das nicht anders. Schreib doch mal 1/3 genau hin. Das 2er-System kann nun andere Zahlen nicht genau speichern, wie z.b. 1/10. Das sieht dann ggf. so aus 0.0999999999 oder 0.1000000001.
Man sollte sich dem immer im klaren sein, und überlegen, was man will. 3D-Koordinaten z.b. kann man ruhig mit Fließkommazahlen speichern, weil es dort nicht wichtig ist, dass die Stellen auf ein Billionstel korrekt ist.
Im Bankwesen, oder generell wenn man mit Geld rechnet, sollte man immer Integer benutzen, da Rundungsfehler immer größer werden können.
Und auch hier in diesem Fall sollte man Integer benuzen, da eine solche Schleife...

for(float i = 0.0; i < 1; i += 0.1) {
}

... schnell mal eine Iteration zu viel ausführen kann. Nach 10 Iterationen könnte der Wert bei 0.9999999 liegen, und eine 11. nicht erwünschte Iteration wird ausgeführt.

lg Kevin

 

[Harry Kane]

Warum so kompliziert. Wenn ich immer mit hundersteln rechne dann habe ich keine Rundungsfehler. Ich rechne grundsätzlich nur mit Fließkomma wenn ich große Zahlen brauche. Wenn ich weiß, dass meine Zahlen in einen Integer passen, dann benutze ich den auch, denn der ist nicht nur genauer, er ist auch um ein vielfaches schneller und speicher sparender.

Es gibt z.B. überhaupt keinen Grund Maße oder Währungen mit Fließkomma zu rechnen.

Gruß

Claus

Wenn die TE tatsächlich mit Größen rechnet, die in ganzzahlige Werte runtergebrochen werden können (Cent, Sekunden, Nanometer,...) , stimme ich dir zu. Nur hat die TE ja explizit gesagt, daß das nicht geht, und ich neige im Gegensatz zu dir dazu, ihr das bis zum Beweis des Gegenteils zu glauben. Sie wird schon ihre Gründe haben, vielleicht auch nicht.
Mich würde eher interessieren, warum mehrere hundert Male ein Wert um ein Zehntel oder 0.1 erhöht werden muss. Dann kann ich auch gleich 0.1 * anzahlDerDurchgänge rechnen und das Ergebnis zum Anfangswert addieren.
Solange der Kontext, in dem diese Rechnung durchgeführt wird, unklar ist, erübrigt sich eine weitere Diskussion.

 

[Wurstkopp]

Da es glaube ich noch nicht erwähnt wurde:

Ist dir Genauigkeit wichtiger als Performance könnte BigDecimal eine brauchbare Lösung für dich sein,