Zitat von Kampi

was mache ich falsch?

Du rufst dir nicht das minimale Grundwissen in Erinnerung, das du in Grundzüge der Informatik über Numerik erworben hast.
Die Kurzfassung: Computer können nicht rechnen, und wenn es um Subtraktion geht, sind die Ergebnisse ganz besonders phantasievoll frei erfunden.

du machst gar nix falsch - es liegt an den Gleitkommazahlen, die du verwendest.
die werden intern aufgeteilt in mantisse und exponent - daurch geht information verloren, weil es keine absolute genauigkeit gibt. deshalb kann es manchmal zu absurden ergbenissen kommen.
siehe auch http://de.wikipedia.org/wiki/Gleitkomm…kommaarithmetik

dein Fehler - du rechnest im Kopf nicht binär, solltest du dir langsam angewöhnen:
http://en.wikipedia.org/wiki/Floating_…_floating-point

Demo

Ich weiß nicht wie oft ich schon float/real/double Werte miteinander verglichen habe. Allerhöchstens mit Toleranz. Vielleicht ist das für dich auch akzeptabel?

Zitat von Kampi

wenn ich auf 'float' caste, dann funktionierts.

das stimmt vielleicht in diesem fall, aber dafür stimmen dann andere rechnungen wieder nicht. ein cast auf float bringt rein gar nichts. am ehesten funktionierts noch wenn du eine kleine toleranz akzeptierst.

Kurz gesagt: Nur Halbe, Viertel, Achtel, Sechzehntel (...) und diverse Zusammensetzungen sind genau darstellbar. 0.7 kriegst du nicht genau hin.

Am einfachsten mit Toleranz vergleichen, statt if (x=0.7) schreibst halt if (abs(x-0.7) < 0.0000001) oder so.

jup, gleitkommazahln sollt man nie exakt vergleichn sondern immer mit einem kleinen delta.

sinnvoll ist es fl oder double zu runden und dann erst zu vergleichen und die abweichung einbeziehen beim vergleichen

zu runden und dann erst zu vergleichen? was ist z.B. mit 3,48 und 3,51? Das wär nach dem Runden dann 3 und 4...

nein, du rundest natürlich nicht auf 0 Kommastellen sondern z.B. auf 5 Kommastellen genau! damit bleibt 3.48 auch 3.48, aber 1.234567 ist dann halt1.23457

Was hätte das für einen Vorteil?

Das funktioniert eben nicht. Das Rundungsergebnis wird in genausoeinem Float-Register gespeichert, wie die Zahl vorher, da gibts auch dieselben Probleme.
Mit Toleranz vergleichen, oder nen Integer zu einer Fixkommazahl umbauen, das kann funktionieren.

Zitat von Wolfibolfi

Das funktioniert eben nicht. Das Rundungsergebnis wird in genausoeinem Float-Register gespeichert, wie die Zahl vorher, da gibts auch dieselben Probleme.
Mit Toleranz vergleichen, oder nen Integer zu einer Fixkommazahl umbauen, das kann funktionieren.

warum nicht ich meine eine zwangs casten oder halt eine abrundung machen bspw nach 3 stellen nach den kommer mit round() .

Tja, wenn du binär rundest, dann funktionierts. Da müsstest du aber 0,8(10) auf 0,75(10) runden, weil da 0,11001...(2) auf 0,11(2) gerundet wird.

Und gefühlsmäßig ist 0,8 zwar ein gerundetes 0.75, im Binärsystem ists aber umgekehrt. Denk nicht im Dezimalsystem, das bringt dir nix.

Verwend java.math.BigDecimal zum exakten Rechnen mit arbitrary-precision Dezimalzahlen in Java.

Zitat von Spockman

Verwend java.math.BigDecimal zum exakten Rechnen mit arbitrary-precision Dezimalzahlen in Java.

ist es das was du gemeint hast?

import java.math.*;


public class Test{

    public static void main(String args[]){

        double d1 = 3.2;
        double d2 = 2.5;
        System.out.println(d1-d2);

        BigDecimal b1 = new BigDecimal(3.2);
        BigDecimal b2 = new BigDecimal(2.5);
        System.out.println(b1.subtract(b2));

        double result = b1.subtract(b2).doubleValue();
        System.out.println(result);
    }
}

Trux@NOTEBOOK~
$ java Test
0.7000000000000002
0.70000000000000017763568394002504646778106689453125
0.7000000000000002

Zitat von Trux

ist es das was du gemeint hast?

Nein.

import java.math.BigDecimal;


public class Test{
    public static void main(String[]){
        BigDecimal b1 = new BigDecimal("3.2");
        BigDecimal b2 = new BigDecimal("2.5");
        System.out.println(b1.subtract(b2));
    }
}

$ java Test
0.7