new | ask | show | jobs
wodenokoto 4 days ago  [ - ]

My gut reaction is that both NaN == NaN and NaN != NaN should be false, it to put it another way, NaN != NaN returns True was a surprise to me.

Does Numpy do the same? That’s where I usually meet NaN.

nyrikki 4 days ago  [ - ]

In a perfect world, in my opinion is that they are incompatibles, and the equality operation should return False in both cases.

But equality is a very complicated concept.

I guess if the values are incomparable != preserves PEM

But Boolean algebra is a lattice, with two+ binary operators were two of those are meet and join with a shared absorbing property.

X == not not X being PEM, we lose that in NP vs co-NP and in vector clocks etc…

But that is just my view.

Pinus 4 days ago  [ - ]

For the built-in float type in Python, the behaviour is a bit funny:

    >>> nan=float('nan')
    >>> a=[nan]
    >>> nan in a
    True
    >>> any(nan==x for x in a)
    False
(Because the `in` operator assumes that identity implies equality...)
dragonwriter 4 days ago  [ - ]

Well no, the in operator is just defined to produce results equivalent equivalent to any(nan is x or nan==x for x in a); it is counterintuitive to the extent people assume that identity implies equality, but the operator doesn't assume that identity implies equality, it is defined as returning True if either is satisfied. [0]

Well, more precisely, this is how the operator behaves for most built in collections; other types can define how it behaves for them by implementing a __contains__() method with the desired semantics.

[0] https://docs.python.org/3/reference/expressions.html#members...

iNic 4 days ago  [ - ]

Yes, in numpy we also have that `np.float64(nan) != np.float64(nan)` evaluates to true.