Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!

# query regarding "=="

Kaush Kane
Ranch Hand
Posts: 37
Hi,
Double a = new Double(Double.NaN);
Double b = new Double(Double.NaN);

if( Double.NaN == Double.NaN )
System.out.println("True");
else
System.out.println("False");

The above program gives me the output:
False.

I thought it wud give me "True".
Wud plz some body explain why its False???

Keith Lynn
Ranch Hand
Posts: 2409
That is a feature of NaN. It is not equal to itself.

Kaush Kane
Ranch Hand
Posts: 37
That is a feature of NaN. It is not equal to itself.

Will you please tell me why it's that way??

Keith Lynn
Ranch Hand
Posts: 2409
This is from the Java Language Specification.

NaN is unordered, so the numerical comparison operators <, <=, >, and >= return false if either or both operands are NaN (�15.20.1). The equality operator == returns false if either operand is NaN, and the inequality operator != returns true if either operand is NaN (�15.21.1). In particular, x!=x is true if and only if x is NaN, and (x<y) == !(x>=y) will be false if x or y is NaN.

Kaush Kane
Ranch Hand
Posts: 37
I have not really understood it.
Based on the discussion I tried the following example:

Double a = new Double(Double.NaN);
Double b = new Double(Double.NaN);
if( Double.NaN == Double.NaN )
System.out.println("True");
else
System.out.println("False");

if( a.equals(b) )
System.out.println("True");
else
System.out.println("False");

When using "==" operator I recieved the output as False
while using "equals" I recieved the output as True.

Keith Lynn
Ranch Hand
Posts: 2409
This is from the API docs for Double.

If d1 and d2 both represent Double.NaN, then the equals method returns true, even though Double.NaN==Double.NaN has the value false.

So the equals method of Double will return true if both are Nan, but the comparison operator will return false.

Kaush Kane
Ranch Hand
Posts: 37
If d1 and d2 both represent Double.NaN, then the equals method returns true, even though Double.NaN==Double.NaN has the value false.

Thanks a lot Keith for your replies...
But this what i m not really understanding as to how the "equals" is returning true while "==" is not.

Sorry for posting frequent questions...

Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
I read your post in disbelief. Then I read the API. Let me apologize for this heinous abomination put forth by Sun. They should be completely ashamed of them selves making Double.NaN == Double.NaN return false.

This is a HIGH abomination.

No, you shouldn't understand this because it is completely backward for how == is supposed to behave. Im very disappointed in Sun

Keith Lynn
Ranch Hand
Posts: 2409
The equals method in Double depends on the native class method doubleToLongBits.

This is the implementation of equals.

So apparently doubleToLongBits when applied to NaN is returning a fixed value each time it is called during the execution of a program.

The reason == returns false is that that is part of the Java Language Specification.

If == were to return true, then it would be like saying, something that is not a number must be equal to something else that is not a number.

Logically, NaN is not a quantity, it doesn't exist, even though technically it has to be given some value in a program.

So we shouldn't expect logical operations to work with NaN.
[ June 19, 2006: Message edited by: Keith Lynn ]

Ernest Friedman-Hill
author and iconoclast
Marshal
Posts: 24212
35
Originally posted by Mr. C Lamont Gilbert:
I read your post in disbelief. Then I read the API. Let me apologize for this heinous abomination put forth by Sun. They should be completely ashamed of them selves making Double.NaN == Double.NaN return false.

This is a HIGH abomination.

Ummm.... you might want to leave Sun alone and take this up with the IEEE 754 committee. Here is a non-Java-related secondary reference which describes this property of NaN (the standard itself isn't free.)

Scott Selikoff
author
Saloon Keeper
Posts: 4020
18
Originally posted by Ernest Friedman-Hill:

Ummm.... you might want to leave Sun alone and take this up with the IEEE 754 committee. Here is a non-Java-related secondary reference which describes this property of NaN (the standard itself isn't free.)

I concur, you should understand why something like this is done before making comments, the writers had good reasons. And either way, it is the way it is so get used to it (unless you join the committee).

I've noticed a lot of posters disagree with the way java works (see multiple inheritence) and don't understand that there are times the writers of java specifically chose things to be the way they are after considering other possibilities. Its not that they 'couldn't fathom doing it other ways', its more that what the choose was believed to be the best after years of practice and experience.... although there are some exceptions to that but I'll leave that as an exercise to the reader

Campbell Ritchie
Sheriff
Posts: 49789
69
This is a HIGH abomination.

But when you consider that NaN is defined as 0/0, let us do some algebra.
Let x be a number. Let us try
x = 0 / 0.
Now, multiplying both sides by 0 give us,
0.x = 0.
Now, if x = 2, substitute 2 for x and we get
0 * 2 = 0.
Which is correct. But if we substitute 4 for x we get
0 * 4 = 0, which is also correct.
So 0 / 0 = 4, and 0 / 0 = 2.

What it means is that a 0 / 0 could have any value; it is "indeterminate," and it would be dangerous to say
0 / 0 = 0 / 0.

That is why an NaN always returns false when compared to an NaN with the == operator, whereas the isNaN() methods return true.

Ken Blair
Ranch Hand
Posts: 1078
I fail to see how NaN != NaN isn't intuitive and logical. The == operator always compares values and in the case of a double that is literally the value of the double, not the value of a reference pointing at a double. Since in the case of NaN the values are not the same (by definition) why would == ever return true?

Campbell Ritchie
Sheriff
Posts: 49789
69
. . . and just for the fun of it, I tried to see what would happen if you cast a NaN. Compile this little trifle:-Does it crash? Does it throw an Exception? Try it and see!

Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15441
41
It surprises me that nobody yet noticed the following:

The == operator compares object references. If you have two Double objects, as you have in your source code (doesn't matter if the value of both Double objects is Double.NaN or any other value), it will ofcourse return false - because you are only checking if the two references point to the same object, not if the values are the same or not.

It's the same thing as the "==" vs "equals()" problem that every beginning Java programmer encounters when working with String objects.

*edit*: Oh wait, I've been misled by your source code. You do this:

But the first two lines are not relevant at all - you are not using the variables a and b in the code below!
[ June 20, 2006: Message edited by: Jesper Young ]