programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
• Campbell Ritchie
• Jeanne Boyarsky
• Ron McLeod
• Paul Clapham
• Liutauras Vilda
Sheriffs:
• paul wheaton
• Rob Spoor
• Devaka Cooray
Saloon Keepers:
• Stephan van Hulst
• Tim Holloway
• Carey Brown
• Frits Walraven
• Tim Moores
Bartenders:
• Mikalai Zaikin

# Double.NaN question

Greenhorn
Posts: 27
• Number of slices to send:
Optional 'thank-you' note:
Can anybody tell me why(the reason) C is right for following question?
The following code will print
1: Double a = new Double(Double.NaN);
2: Double b = new Double(Double.NaN);
3:
4: if( Double.NaN == Double.NaN )
5: System.out.println("True");
6: else
7: System.out.println("False");
8:
9: if( a.equals(b) )
10: System.out.println("True");
11: else
12: System.out.println("False");
A) True
True
B) True
False
C) False
True
D) False
False
Jenny

Author and all-around good cowpoke
Posts: 13078
6
• Number of slices to send:
Optional 'thank-you' note:
Ewww that is tricky! We know that Double.NaN == Double.NaN as a comparison of double values returns false, so naturally we expect the equals method to fail too.
Unfortunately, the Double equals method is:
public boolean equals(Object obj) {
return (obj != null)
&& (obj instanceof Double)
&& (doubleToLongBits(((Double)obj).value) ==
doubleToLongBits(value));
}
which instead of comparing double == double uses the doubleToLongBits conversion so the == ends up comparing the bit patterns - which are equal. This unexpected result IS cited in the Javadocs.
Bill

------------------
author of: