Confusión sobre NaN en Java

Question

int i = 0, j = 0; 
double nan1 = (double)0/0; 
double nan2 = (double)0/0; 
double nan3 = (double)i/j; 
System.out.println(Double.doubleToRawLongBits(nan1) == Double.doubleToRawLongBits(nan2)); 
System.out.println(Double.doubleToRawLongBits(nan1) == Double.doubleToRawLongBits((double)0/0)); 
System.out.println(Double.doubleToRawLongBits(nan3) == Double.doubleToRawLongBits(nan2)); 

de salida:

true 
true 
false 

favor me ayude cómo se produjo la salida de true dos primeros y false para la última. Por favor dígame qué es el trabajo real del método Double.doubleToRawLongBits().

Answer 1

Por favor, intente ejecutar código siguiente para ver los valores:

public class Test 
{ 
    public static void main(String[] args){ 
     int i = 0, j = 0; 
     double nan1 = (double)0/0; 
     double nan2 = (double)0/0; 
     double nan3 = (double)i/j; 
     System.out.println(Double.doubleToRawLongBits(nan1) + " == "+ Double.doubleToRawLongBits(nan2) + " is " + 
      (Double.doubleToRawLongBits(nan1) == Double.doubleToRawLongBits(nan2))); 
     System.out.println(Double.doubleToRawLongBits(nan1) + " == "+ Double.doubleToRawLongBits((double)0/0) + " is " + 
      (Double.doubleToRawLongBits(nan1) == Double.doubleToRawLongBits((double)0/0))); 
     System.out.println(Double.doubleToRawLongBits(nan3) + " == "+ Double.doubleToRawLongBits(nan2) + " is " + 
      (Double.doubleToRawLongBits(nan3) == Double.doubleToRawLongBits(nan2))); 
    } 
} 

en mi Mac, Produce salida siguiente:

9221120237041090560 == 9221120237041090560 is true 
9221120237041090560 == 9221120237041090560 is true 
-2251799813685248 == 9221120237041090560 is false 

este escollo se documenta en el Javadoc para la doubleToRawLongBits method:

Si el argumento es NaN, el resultado es el largo entero que representa el valor real NaN. A diferencia del método doubleToLongBits, doubleToRawLongBits no contrae todos los patrones de bits que codifican un NaN a un único valor NaN "canónico".

Answer 2

Creo que Java sigue a IEEE 754. En este caso NaN tiene más de una posible representación de bits. Las dos representaciones en su caso difieren en el bit "signo". El valor del bit de signo parece no estar definido por el estándar y generalmente se ignora. Entonces ambos valores son correctos. Ver http://en.wikipedia.org/wiki/NaN

Answer 3

La razón es porque cuando se divide una variable doble 0 por 0 se devuelve NaN, por lo que el método tampoco tienen una única representación canónica en binario, por lo que puede devolver el binario de NaN como 7F F8 00 00 00 00 00 00 o F8 FF 00 00 00 00 00 00.

a pesar de que técnicamente representan lo mismo, que es NaN, su diferente en representación binaria.

Answer 4

El estándar IEEE 754 permite diferentes patrones de bits para NaN. Para los propósitos de cálculo y de comparación todos ellos deben funcionar de la misma (es decir NaN no compara igual a sí mismo, no se ordena y cada cálculo que implica NaN es NaN sí mismo). Con doubleToRawLongBits obtienes el patrón de bits exacto utilizado. Esto también se detalla en el JLS:

En su mayor parte, la plataforma Java trata a valores NaN de un tipo dado como aunque colapsado en un solo valor canónica (y por lo tanto esta especificación nor- Mally se refiere a una NaN arbitrario como si fuera un valor canónico). Sin embargo, la versión 1.3 la plataforma Java métodos introducidos permiten al programador para distinguir entre valores NaN: los métodos y Float.floatToRawIntBitsDouble.double- ToRawLongBits. El lector interesado se refiere a las especificaciones para las clases Float y Double para obtener más información.

En el caso de que el bit de signo es diferente, en este caso me puedo dirigir a Wikipedia, que resume esta manera concisa:

En IEEE 754 formatos de almacenamiento de punto flotante que sigan los estándares, se identifican NaNs mediante patrones de bits predefinidos específicos únicos para NaN. El bit de signo no importa.

Ambos valores son NaN, solo usan diferentes bits para representar eso. Algo que es permitido por IEEE 754 y en este caso probablemente proviene del compilador que sustituye Double.NaN por un cálculo constante que resulta en NaN mientras que el hardware real da un resultado diferente, como sospechaba Mysticial en un comentario a la pregunta ya.