¿Por qué Java's Double.compare (doble, doble) está implementado como está?

Question

Estaba viendo la implementación de compare(double, double) en la biblioteca estándar de Java (6). Se lee:

public static int compare(double d1, double d2) { 
    if (d1 < d2) 
     return -1;  // Neither val is NaN, thisVal is smaller 
    if (d1 > d2) 
     return 1;  // Neither val is NaN, thisVal is larger 

    long thisBits = Double.doubleToLongBits(d1); 
    long anotherBits = Double.doubleToLongBits(d2); 

    return (thisBits == anotherBits ? 0 : // Values are equal 
      (thisBits < anotherBits ? -1 : // (-0.0, 0.0) or (!NaN, NaN) 
      1));       // (0.0, -0.0) or (NaN, !NaN) 
} 

¿Cuáles son los méritos de esta implementación?

---

corregir: "Merits" fue una (muy) mala elección de palabras. Quería saber cómo funciona esto.

Answer 1

@ respuesta de Shoover es correcta, pero hay un poco más que esto.

Como los javadoc para Double::equals estados:

"Esta definición permite tablas hash para operar correctamente."

Supongamos que los diseñadores de Java habían decidido implementar equals(...) y compare(...) con la misma semántica que == en los casos double envueltos. Esto significa que equals() siempre devolvería false para un NaN envuelto.Ahora considere lo que sucedería si tratara de usar un NaN envuelto en un Mapa o Colección.

List<Double> l = new ArrayList<Double>(); 
l.add(Double.NaN); 
if (l.contains(Double.NaN)) { 
    // this wont be executed. 
} 

Map<Object,String> m = new HashMap<Object,String>(); 
m.put(Double.NaN, "Hi mum"); 
if (m.get(Double.NaN) != null) { 
    // this wont be executed. 
} 

¡No tiene mucho sentido!

Otras anomalías existirían porque -0.0 y +0.0 tienen patrones de bits diferentes pero son iguales según ==.

Así que los diseñadores de Java decidieron (con razón IMO) en la definición más complicada (pero más intuitiva) para estos métodos dobles que tenemos hoy.

Answer 2

Creo que el mérito principal es que es correcto.

Maneja correctamente NaN y firmó ceros.

Answer 3

Esa implementación permite que un número real se defina como < NaN, y -0.0 como < 0.0.

Answer 4

La explicación está en los comentarios del código. Java tiene valores dobles para 0.0 y -0.0, así como "no es un número" (NaN). No puede usar el operador simple == para estos valores. Echar un vistazo a la fuente de doubleToLongBits() y al the Javadoc for the Double.equals() method:

Tenga en cuenta que en la mayoría de los casos, para los dos instancias de la clase Double, d1 y d2, el valor de d1.equals(d2) es true si y sólo si

d1.doubleValue() == d2.doubleValue() 

también tiene el valor true. Sin embargo, hay dos excepciones:

• Si d1 y d2 ambos representan Double.NaN, entonces el método es igual regresos true, incluso aunque Double.NaN == Double.NaN tiene el valor false.
• Si d1 representa +0.0 mientras d2 representa -0.0, o viceversa, la prueba de igualdad tiene el valor false, a pesar de que +0.0 == -0.0 tiene el valor true.

Answer 5

El mérito es que es el código más simple que cumple con la especificación.

Una característica común de los programadores novatos es sobrevalorar el código fuente de lectura y infravalorar la lectura especificaciones. En este caso, la especificación:

http://java.sun.com/javase/6/docs/api/java/lang/Double.html#compareTo%28java.lang.Double%29

... hace que el comportamiento y la razón para el comportamiento (coherencia con los iguales()) perfectamente claras.