Pourquoi la fonction Double.compare(double, double) de Java est-elle implémentée de cette manière ?

Question

Je regardais l'implémentation de compare(double, double) dans la bibliothèque standard de Java (6). Il se lit comme suit :

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)
}

Quels sont les mérites de cette mise en œuvre ?

---

edit : "Merits" était un (très) mauvais choix de mots. Je voulais savoir comment cela fonctionne.

Answer 1

L'explication se trouve dans les commentaires du code. Java a des valeurs doubles pour les deux 0.0 y -0.0 ainsi que "pas un numéro" ( NaN ). Vous ne pouvez pas utiliser de simples == pour ces valeurs. Jetez un coup d'œil à la doubleToLongBits() et à la Javadoc pour le Double.equals() méthode :

Notez que dans la plupart des cas, pour deux instances de la classe Double , d1 y d2 , la valeur de d1.equals(d2) est true si et seulement si

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

a également la valeur true . Cependant, il y a deux exceptions :

• Si d1 y d2 les deux représentent Double.NaN alors la méthode equals renvoie true même bien que Double.NaN == Double.NaN a la valeur false .
• Si d1 représente +0.0 tandis que d2 représente -0.0 ou vice versa, le test d'égalité a pour valeur false même si +0.0 == -0.0 a la valeur true .

Cette définition permet aux tables de hachage de fonctionner correctement.

Answer 2

La réponse de @Shoover est correcte ( Lisez-le ! ), mais il y a un peu plus que cela.

Comme le javadoc pour Double::equals États :

"Cette définition permet aux tables de hachage de fonctionner correctement."

Supposons que les concepteurs de Java aient décidé d'implémenter equals(...) y compare(...) avec la même sémantique que == sur l'emballage double instances. Cela signifie que equals() retournerait toujours false pour un NaN enveloppé. Imaginez maintenant ce qui se passerait si vous essayiez d'utiliser un NaN enveloppé dans une carte ou une collection.

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.
}

Ça n'a pas beaucoup de sens, n'est-ce pas ?

D'autres anomalies existeraient parce que -0.0 y +0.0 ont des configurations binaires différentes mais sont égales selon == .

Les concepteurs de Java ont donc opté (à juste titre, selon moi) pour la définition plus compliquée (mais plus intuitive) de ces méthodes doubles que nous avons aujourd'hui.

Answer 3

Je pense que le principal mérite est que c'est correct.

Il gère correctement les NaN et les zéros signés.

Answer 4

Le mérite est que c'est le code le plus simple qui remplit la spécification.

Une caractéristique commune aux programmeurs débutants est de surévaluer la lecture du code source et de sous-évaluer la lecture spécifications . Dans ce cas, le spec :

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

... rend le comportement et le la raison du comportement (cohérence avec equals()) parfaitement claire.

Answer 5

Cette implémentation permet de définir un nombre réel comme < NaN, et -0,0 comme < 0,0.