On Sun, Oct 07, 2012 at 10:35:17PM -0400, Ned Batchelder wrote:
A sentence in section 5.4 (Numeric Types) would help. Something like, "In accordance with the IEEE 754 standard, NaN's are not equal to any value, even another NaN. This is because NaN doesn't represent a particular number, it represents an unknown result, and there is no way to know if one unknown result is equal to another unknown result."
NANs don't quite mean "unknown result". If they did they would probably be called "MISSING" or "UNKNOWN" or "NA" (Not Available).
NANs represent a calculation result which is Not A Number. Hence the name :-) Since we're talking about the mathematical domain here, a numeric calculation that doesn't return a numeric result could be said to have no result at all: there is no real-valued x for which x**2 == -1, hence sqrt(-1) can return a NAN.
It certainly doesn't mean "well, there is an answer, but I don't know what it is". It means "I know that there is no answer".
Since neither sqrt(-1) nor sqrt(-2) exist in the reals, we cannot say that they are equal. If we did, we could prove anything:
sqrt(-1) = sqrt(-2)
Square both sides:
-1 = -2
I was not on the IEEE committee, so I can't speak for them, but my guess is that they reasoned that since there are an infinite number of "no result" not-a-number calculations, but only a finite number of NAN bit patterns available to be used for them, it isn't even safe to presume that two NANs with the same bit pattern are equal since they may have come from completely different calculations.
Of course this was before object identity was a relevant factor. As I've stated before, I think that having collections choose to optimize away equality tests using object identity is fine. If I need a tuple that honours NAN semantics, I can subclass tuple to get one. I shouldn't expect the default tuple behaviour to carry that cost.
By the way, NANs are awesome and don't get anywhere near enough respect. Here's a great idea from the D language: