I just fixed two bugs in DrJava that had to do with boxed floating-point comparisons of NaN and -0.0.
Both bugs had the same cause, a difference between the behavior of primitive
== and the
equals method in
According to IEEE 754, any NaN isn’t equal to anything, not even itself. Therefore,
Double.NaN==Double.NaN should evaluate to false. On the other hand, positive and negative zero are the same (even though they have different encodings), so
0.0==-0.0 should evaluate to true. This is the case for the primitive types
float, but not for the boxed types
This may be surprising, but the boxed types had additional contracts to fulfill regarding the behavior of
hashCode in hash tables. It was decided that it was more important to successfully look up floating-point values in hash tables, so
new Double(Double.NaN).equals(new Double(Double.NaN)) returns true, and
new Double(0.0).equals(new Double(-0.0)) returns false. Try it.
In Dynamic Java, the interpreter in DrJava, we internally used boxed types when comparing primitives, just because that way, we could write the equals method more easily. Now I created special cases for floating-point numbers that unboxes the values and eschews the