Hi All, Can I make any assumptions about the value of non-canonical NaNs ? I have been experimenting and reading the JLS but am not confident that I have a definitive answer.
Briefly, in R floating point values can take a special NA (statistically missing or "Not Available") that is a class of NaN but is treated quite distinctly throughout the language (NaN is NA, but NaN is not necessarily NaN). In the existing R Interpreter, NAs are represented internally as "signaled NaN" with a payload of 0x1954. I got into trouble because JVM mostly, but not always, silently drops the signaling bit, so (1) Double.doubleToRawLongBits(Double.longBitsToDouble(0x7ff0000000001954L)) ! = 0x7ff0000000001954L (mostly) Now, what does seem to be reliable is that the payload (0x1954) is preserved: (2) Double.doubleToRawLongBits(Double.longBitsToDouble(0x7ff8000000001954L)) == 0x7ff8000000001954L (in all my tests) So this working fine, tests are passing, but do I have guarantees that (2) will hold true across all correct JVM implementations and on all platforms, or am I rolling the dice? The JLS says: "IEEE 754 allows multiple distinct NaN values for each of its single and double floating-point formats. While each hardware architecture returns a particular bit pattern for NaN when a new NaN is generated, a programmer can also create NaNs with different bit patterns to encode, for example, retrospective diagnostic information." http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3 but the javadoc for Double.longBitsToDouble says: "Note that this method may not be able to return a double NaN with exactly same bit pattern as the long argument. IEEE 754 distinguishes between two kinds of NaNs, quiet NaNs and signaling NaNs. The differences between the two kinds of NaN are generally not visible in Java. Arithmetic operations on signaling NaNs turn them into quiet NaNs with a different, but often similar, bit pattern. However, on some processors merely copying a signaling NaN also performs that conversion. In particular, copying a signaling NaN to return it to the calling method may perform this conversion. So longBitsToDouble may not be able to return a double with a signaling NaN bit pattern. Consequently, for some long values, doubleToRawLongBits(longBitsToDouble(start)) may not equal start. Moreover, which particular bit patterns represent signaling NaNs is platform dependent; although all NaN bit patterns, quiet or signaling, must be in the NaN range identified above." So I understand the signaling bit is not guaranteed to be preserved, but can I safely assume that the payload will not be touched (as appears to be the case) ? Thanks, Alex -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
