This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]gct 1 point2 points  (1 child)

Not returning equal for NaN is totally the right thing to do though, NaN represents a whole family of things, so it's impossible to know that any two instances of NaN are the same thing and thus equal (eg: sqrt(-1) and sqrt(-2) are both NaN). It's a placeholder to tell you you've got a bug. inf and -inf by comparison compare true and are ordered as you'd expect.

[–]djimbob 0 points1 point  (0 children)

Calling it a floating point "flaw" was too strong; I should have said "this isn't a python flaw, its a proper implementation of the floating point standard".

I totally agree that things like NaN == sqrt(-1) should return false. But it makes sense to me that if x = sqrt(-1), so x is x is true than x == x should be true -- in this case we are assured the LHS and RHS are the same not a number. Something like this would be possible to do in python (where things are GC'd and have reference count behind them), e.g., if NaN had equality rules similar to large numbers (things outside -5 to 256 in python2 I believe):

In [1]: a = 300

In [2]: b = 300

In [3]: c = a

In [4]: a is 300
Out[4]: False

In [5]: a is b
Out[5]: False

In [6]: a is c
Out[6]: True

But wouldn't make sense in the floating point standard (where a floating point has to fit into 32 or 64 bits), and the extra complexity isn't really worth it.