double Vergleich

[Neumi5694]

Kurze Frage, vielleicht weiß da jemand was. Immer wieder stolpert man in diversen Sourcecodes über diesen Ausdruck,
[CODE lang="java" title="z.B. in Double.compare(...)"]boolean isEqual = Double.doubleToLongBits(d1) == Double.doubleToLongBits(d2);[/CODE]
An anderen Orten wird einfach verglichen:
[CODE lang="java" title="z.B. in Point2D.compare(...)"]boolean isEqual = d1 == d2;[/CODE]

Was spricht für die eine Methode, was für die andere (Performance, Genauigkeit, sonstwas)?
Oder wird gar der untere Ausdruck beim Kompilieren in den oberen umgeschrieben?

 

[kneitzel]

JLS 15.21.1 beschreibt den Vergleich mit ==, dabei ist wichtig, dass x != x true ist, wenn x NaN ist.

Bei doubleToLongBits (Methode ist ja dokumentiert!) ist NaN 0x7ff8000000000000L und damit würden zwei NaN Werte als gleich angesehen.
Das dürfte der Hauptunterschied sein.

 

[Neumi5694]

Ah, an NaN hab ich nicht gedacht. Das hat für mich gedanklich keine Rolle gespielt. Danke.

 

[mihe7]

Bei +/-0 macht es auch einen Unterschied.

 

[Neumi5694]

Bei +/-0 macht es auch einen Unterschied.

Zuerst dacht ich, das wäre nicht richtig. Der Compiler ersetzte die direkte Zuweisung -0 nach 0, auch (0 * -60) war auf beide Arten gleich 0. Es ging erst, als ich mit (-60 * 0) verglich. Das zeigt wieder mal, wie wichtig die Reihenfolge in Ausdrücken ist

 

[mihe7]

0d == -0d aber Double.doubleToLongBits(0d) != Double.doubleToLongBits(-0d)

 

[Neumi5694]

  public static void main(String[] args) {
    System.out.println(0 == -0);
    System.out.println(Double.doubleToLongBits(0) == Double.doubleToLongBits(-0));
    System.out.println(Double.doubleToRawLongBits(0) == Double.doubleToRawLongBits(-0));
    double d1 = 0;
    double d2 = -0;
    System.out.println(d1 == d2);
    System.out.println(Double.doubleToLongBits(d1) == Double.doubleToLongBits(d2));
    System.out.println(Double.doubleToRawLongBits(d1) == Double.doubleToRawLongBits(d2));
    double d3 = 60 * 0;
    double d4 = -60 * 0;
    System.out.println(d3 == d4);
    System.out.println(Double.doubleToLongBits(d3) == Double.doubleToLongBits(d4));
    System.out.println(Double.doubleToRawLongBits(d3) == Double.doubleToRawLongBits(d4));
  }

Ausgabe mit JDK 17:
true
true
true
true
true
true
true
true
true

Keine Ahnung, wie ich's vorhin geschafft hab, mal false rauszukriegen, vielleicht ein Tippfehler.

Auf jeden Fall ist die Frage eh beantwortet, danke

 

[mihe7]

System.out.println(Double.doubleToLongBits(0) == Double.doubleToLongBits(-0));

Das Problem ist, dass Du hier mit int-Literalen arbeitest und da ist -0 natürlich gleich 0. Wenn Du double-Literale nimmst, dann wird das zu false.

 

[Neumi5694]

Doh!
Besonders in den Fällen mit double-Variablen wundert mich das aber schon. Der Compiler ersetzt das nicht so, wie ich's bisher angenommen hab.

 

[Gelöschtes Mitglied 65838]

fancy wirds auch wenn du mit konstanten arbeitest zb
das ist erlaubt

final byte x = 0;
final byte y = 0;
byte z = x + y;

das ist nicht erlaubt und wird nen fehler werfen, weil du es noch nach byte casten müsstest

 byte x = 0;

 byte y = 0;

byte z = x + y;

 

[mihe7]

das ist erlaubt

Das sieht meine JShell anders:

jshell> final byte x = 0;
   ...> final byte y = 0;
   ...> byte z = x + y;
x ==> 0
y ==> 0
|  Error:
|  incompatible types: possible lossy conversion from int to byte
|  byte z = x + y;
|           ^---^

Für den Compiler ist es ok

 

[Gelöschtes Mitglied 65838]

Das sieht meine JShell anders:

jshell> final byte x = 0;
   ...> final byte y = 0;
   ...> byte z = x + y;
x ==> 0
y ==> 0
|  Error:
|  incompatible types: possible lossy conversion from int to byte
|  byte z = x + y;
|           ^---^

Für den Compiler ist es ok

probier es in eclipse oder intellij ... ka was die jshell macht .. kopier das in die main rein

    final byte x = 4;
    final byte y = 3;
    byte z = x + y;
    System.out.println(z);

soweit ich weis macht der compiler dadurch dass es final ist schon irgendwas mit dem datentyp und deswegen funktionierts... hatte das mal wo aufgeschnappt und bin mir 100% sicher dass das in einem normalen java programm funktioniert

bei mir kommt auch die 7 raus

jetzt fehlt mir wieder knietzel der findet immer so ne JLS definition die perfekt passt

 

[httpdigest]

jetzt fehlt mir wieder knietzel der findet immer so ne JLS definition die perfekt passt

Wo ist er denn? (war ein paar Tage nicht hier auf java-forum.org und plötzlich steht bei seinem User nur noch "Gast"....) Was ist los?

 

[Gelöschtes Mitglied 65838]

er wollte seinen Acc gelöscht haben, im Martin Sellner post hatte er paar sachen erwähnt

zb dass es ihm auf den sack gegangen ist dass leute deklariert und initialisiert nicht richtig bneutzt haben und wenn man eine JLS Link hinlegt die leute diskutieren dass das was im JLS link drin steht nicht richtig sein soll.. oder was er explizit erwähnt hatte

Irgendein User: mach var weg

Erfahrernenr : var gibts seit java 10

Irgendein User: mach trotzdem das var weg sieht nicht richtig aus

 

[mihe7]

soweit ich weis macht der compiler dadurch dass es final ist schon irgendwas mit dem datentyp und deswegen funktionierts...

Ja, mich hatte es gewundert, dass die JShell das anders sieht. Liegt vermutlich daran, dass man Variablen redeklarieren kann, wenn man es in eine Klasse packt, funktioniert es auch dort.

Und ja, der Compiler ersetzt x+y durch das Ergebnis. Wenn Du z. B. x = 127 und y = 3 setzt, bekommst Du einen Fehler.

Wo ist er denn? (war ein paar Tage nicht hier auf java-forum.org und plötzlich steht bei seinem User nur noch "Gast"....) Was ist los?

Keine Ahnung, was da passiert ist. Er hat irgendwo angekündigt, dass er bald weg sein wird und auf meine Frage, was passiert sei, hat er nicht geantwortet. In einem anderen Thread hat er geschrieben, dass er keinen Bock mehr auf überflüssige Diskussionen hat.

 

[Gelöschtes Mitglied 65838]

Und ja, der Compiler ersetzt x+y durch das Ergebnis. Wenn Du z. B. x = 127 und y = 3 setzt, bekommst Du einen Fehler.

ja gut, meine aussage war auch auf das Casten ansich bezogen dass es da fancy sachen gibt die man sich mal anschauen kann

 

[httpdigest]

By the way, hier ist die JLS Erklärung: https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.2

In addition, if the expression is a constant expression (§15.28) of type byte, short, char, or int:

• A narrowing primitive conversion may be used if the type of the variable is byte, short, or char, and the value of the constant expression is representable in the type of the variable.

Das "final" macht also aus der Variablen eine "Konstante" und dann kann der Compiler schon zur Compilezeit (constant-folding) den finalen Wert von `z` berechnen (siehe javap Output unten für deinen Code). Natürlich wäre die Variable effektiv auch ohne das final noch konstant (weil kein weiterer Wert zugewiesen wird), das prüft aber der Compiler wohl nicht explizit ab.

javap -v output:

 0: iconst_4
 1: istore_1
 2: iconst_3
 3: istore_2
 4: bipush        7 // <- gleich 7!
 6: istore_3
 7: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
10: iload_3
11: invokevirtual #13                 // Method java/io/PrintStream.println:(I)V

 

[Gelöschtes Mitglied 65838]

das prüft aber der Compiler wohl nicht explizit ab.

ja dann wird nach einem Expliziten cast verlangt nach Byte

 

[mihe7]

By the way, hier ist die JLS Erklärung:

Weil wir gerade beim Thema kneitzel waren: ah, ein Freiwilliger

Außedem: der Konrad hält das eh nicht durch, so ohne Java-Forum.

 

[Neumi5694]

er wollte seinen Acc gelöscht haben, im Martin Sellner post hatte er paar sachen erwähnt

zb dass es ihm auf den sack gegangen ist dass leute deklariert und initialisiert nicht richtig bneutzt haben und wenn man eine JLS Link hinlegt die leute diskutieren dass das was im JLS link drin steht nicht richtig sein soll.. oder was er explizit erwähnt hatte

Das klingt verdammt nach "Bring Popcorn mit"