Why a NaN variable is not equal to Double.NaN?

Newbie & Debugging Questions
#1

In the picture shown, Eclipse is telling me that the double variable, “unprocessed”, is NaN. However, when comparing it to Double.NaN, it tells me the Boolean value is “false”.

Why? And how do I fix it?

#2

Do the following:

double x = ... 
if (Double.isNaN(x)) {
    ...
}
#3

Thanks, stranger, totally fixed the NaN problem I keep having. Fitting name, by the way. :point:

#4

Keep in mind that NaN values are not even equal to themselves:

boolean isNaN =   unprocessed != unprocessed; // true
#5

Interesting. Thanks for the tip.

#6

This is an admittedly braindead feature in the language which IMHO breaks one of those principles of least surprise.

Cas :slight_smile:

#7

No: It’s a desirable feature. x != x

#8

autoboxing + NaN = potential for much pain

#9

I mean if you really think about it, how can two “numbers” that aren’t even numbers be equal to each other? If they aren’t numbers in the first place… Its kind of hard to be equal to another not number.

#10

Personally I think it makes perfect sense that NaN != NaN. :slight_smile: All we know about “NaN” is that is that it’s not a number, nothing more, hence we don’t know if they’re equal. :slight_smile:

#11

The IEEE standard is pretty well thought out. The way the special values: NaN, Infs and signed zeroes all have reasons.

#12

The problem is that when we say == we are usually not exactly referring to mathematical equality but simply trying to say “is this not a number”. Which is exactly how you read if x == NaN. It’s just plain daft to need a method call to say this as it leads to very subtle errors, almost always in edge cases because NaN very rarely appears. It’s rather like how the designers of SQL thought they were being clever by insisting we use IS NULL and IS NOT NULL rather than = NULL and <> NULL. Foolish.

Cas :slight_smile:

#13

Not at all. The reason is sound. If you don’t want to call a method then if (x != x) is only true if NaN and if (x==x) is true for any non-NaN. Having NaN==NaN would drastically complicate a fair number of numeric routines.

#14

I don’t quite follow that… have you got some particular use-cases as example?

(I think the real reason NaN != NaN is because there are > 1 binary representations of NaN but there we go)

Cas :slight_smile:

#15

[icode]if (a == b)[/icode] would have to become [icode]if (a == b && !isNaN(a))[/icode] as an example

#16

I must be being dense but I still don’t follow that.

Cas :slight_smile:

#17

While I lean towards your viewpoint Princec, I do understand Roquen’s example after thinking about it for a moment.

If a == NAN, b == NAN, and NAN == NAN, then you would need the extra check in the example given. While a would equal b, neither a nor b would be guaranteed to be valid numbers within the scope of the if statement, thus the extra check for !isNAN.

I would think a more “Java-centric” approach would have been a “NAN exception”, but I imagine the extra overhead of the implementation would have a larger impact on performance than one might initially think.

Just my $0.02. ???

#18

Still don’t get it :emo:

Let’s just for the sake of a straw man declare that NaN is represented in binary by some magic number eg. 0xFFFFFFFF.

I want to know if a == NaN. Is a == 0xFFFFFFFF? Yes? Good.
I want to know if b == NaN. Is b == 0xFFFFFFFF? Yes? Good.
I want to know if a == b. I’m entirely happy with a == b being true for any values of a and b. I’m also happy that if NaN == NaN then a == b here too.
I just want to know is a is NaN or b is NaN.
I’m happy that NaN == NaN in my world. That makes sense to me. Very much like null == null in Java (but irritatingly, not SQL).

What am I missing?

Cas :slight_smile:

#19

You know that a == b, but what is your guarantee that a and b are usable values for a mathematical operation if NAN == NAN without the extra check mentioned earlier (!isNAN(a))? I think that’s the point Roquen is trying to make.

Also consider that Null is indicative of a single state, so Null == Null makes sense. Without this becoming a discussion of Jean-Paul Sartre, nothing should always equal nothing. Nan indicates that there is a value being pointed to, but it’s not the type of value that we can work with. If I have a box of items that are not apples, does that mean that everything in that box is the same item, or could I have varying items in the box whose only similarity is that they’re not apples? :wink:

Damn, philosophy and code before caffeine is going to make my head hurt. LOL

#20

Indeed, but that usage of NaN is about as useful as a chocolate kettle to most of us.

Cas :slight_smile: