query regarding "=="

[Kaush Kane]

Hi,
Please fidn the following code:

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]

That is a feature of NaN. It is not equal to itself.

[Kaush Kane]

That is a feature of NaN. It is not equal to itself.

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

[Keith Lynn]

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]

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.

Please help solving the above doubt.

[Keith Lynn]

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]

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]

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]

The equals method in Double depends on the native class method doubleToLongBits.

This is the implementation of equals.

public boolean equals(Object obj) {
return (obj instanceof Double)
       && (doubleToLongBits(((Double)obj).value) ==
      doubleToLongBits(value));
    }

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]

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]

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]

This is a HIGH abomination.

My, that is even worse than what I say about addActionListener(this).

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]

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]

. . . and just for the fun of it, I tried to see what would happen if you cast a NaN. Compile this little trifle:-

/**
 * @author Campbell Ritchie}
 *
 * @version 19-Jun-2006
 */
public class NanCrash
{
private double number;
 
/**
 * Create an instance of {class}
 */
public NanCrash()
{
super();
number = 0. / 0.;
}// end constructor
 
/**
 * @param args None required
 */
public static void main(String[] args)
{
System.out.print(new NanCrash().crash());
}// end method main

        /**
         * Cast the Nan number to an int.
         * @return the NaN cast to an int.
         */
public int crash()
{
return (int)number;
}
}// end class    

Does it crash? Does it throw an Exception? Try it and see!

[Jesper de Jong]

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:

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");

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 ]