+0 -0 comportamiento y espectáculos diferentes para int y float datos

Bufón :

He leído este post negativa y cero positivo .

Para mi código siguiente entendimiento debe dar truey truecomo salida.

Sin embargo, se está dando falsey truecomo salida.

Estoy comparando cero negativo con un cero positivo.

public class Test {
     public static void main(String[] args) {
            float f = 0;
            float f2 = -f;
            Float F = new Float(f);
            Float F1 = new Float(f2);
            System.out.println(F1.equals(F));

            int i = 0;
            int i2 = -i;
            Integer I = new Integer(i);
            Integer I1 = new Integer(i2);
            System.out.println(I1.equals(I));
      }
  }

¿Por qué tenemos un comportamiento diferente de 0 para de Integery Float?

yshavit:

Enteros y los flotadores son bastante diferentes bestias en Java. Ints se codifican como complemento de dos , que tiene un único valor 0. Los flotadores utilizan IEEE 754 (la variante de 32 bits para los flotadores, y 64-bit en dobles). IEEE 754 es un tanto complejo, pero para el propósito de esta respuesta, sólo tiene que saber que tiene tres secciones, la primera de las cuales es un bit de signo. Eso significa que por cualquier flotador, hay un variant¹ positivo y negativo. Que incluye 0, por lo que flotadores en realidad tienen dos valores "cero", y 0 -0.

Como acotación al margen, el complemento de dos enteros que usan no es la única manera de codificar los números enteros en la informática. Hay otros métodos, como complemento a uno , pero tienen peculiaridades - como tener tanto un 0 y -0 como valores distintos. ;-)

Cuando se comparan las primitivas flotador (y dobles), Java trata a 0 y -0 como iguales. Pero cuando se les caja, Java los trata por separado, como se describe en Float#equals. Esto permite que el método es igual a ser coherente con su hashCodeaplicación (así como compareTo), que sólo utiliza los bits del flotador (incluido el valor con signo) y empujones tal y como son en un int.

Ellos podrían haber elegido alguna otra opción para iguales / hashCode / compareTo, pero no lo hicieron. No estoy seguro de lo que había las consideraciones de diseño. Pero al menos en un sentido, Float#equalssiempre se va a divergir de las primitivas de flotador ==: En primitivas, NaN != NaNsino para todos los objetos, o.equals(o)debe también ser verdad . Eso significa que si usted tenía Float f = Float.NaN, a continuación, f.equals(f)a pesar de que f.floatValue() != f.floatValue().

---

¹ valores NaN (not-a-número) tiene un bit de signo, pero no tiene ningún otro significado que para el pedido, y Java ignora (incluso para el pedido).