nan != nan severely bothers me, when it's the same object on both sides with exactly the same bit pattern. It's the work of imbeciles who are either unfamiliar with the concept of identity, or else don't understand why it's important and should be respected.
It feels like an argument between useful and correct.
Correct is "These two items are not numbers, so the numeric concept of equality can't be conclusively applied." This argument gives you NaN != NaN.
Useful is "We consider everything that's escaped the plane of numbers to be equivalent because they all require the same special handling." This gives you Nan = NaN.
Problem is, there are multiple representations identified as "NaN". The question whether one NaN should be considered equal to another NaN is different from whether a NaN should equal to itself.
Whether a NaN is equal to a different NaN depends on the kind of equality; some equalities don't care about certain differences.
The C == equality allows the integer 1 to equal 1.0, in spite of a different representation; it is not simply a bitwise equality. (This happens by way of conversion of 1 to 1.0).
However, a thing should equal to itself under every applicable equality. That is non-negotiable.
There is a sense in which eq(x, x) can be false, if we consider argument passing to work by copy, and argument position to be part of identity. Then x is not x, because one is the left x and one is the right x they are in different stack locations or machine registers or whatever. Common Lisp allows for this kind of chicanery in its definition of "implementation identity" (embodied in its eq function). Numbers are not required to be eq, even to themselves. (eq 0 0) could yield false, the idea being that each copy of 0 could be a distinct object. Though that sort of stinks, it's not what is at pay here. These NaNs have type double, and ordinary values of that type are equal to themselves when copied to different argument positions of the equality operation.
