On 10/8/2012 12:25 PM, Guido van Rossum wrote:
On Sun, Oct 7, 2012 at 7:35 PM, Ned Batchelder email@example.com wrote:
I don't understand the reluctance to address a common conceptual speed-bump in the docs. After all, the tutorial has an entire chapter (http://docs.python.org/tutorial/floatingpoint.html) that explains how floats work, even though they work exactly as IEEE 754 says they should.
I'm sorry. I didn't intend to refuse to document the behavior. I was mostly reacting to things I thought I read between the lines -- the suggestion that there is no reason for the NaN behavior except silly compatibility with an old standard that nobody cares about. From this it is only a small step to reading (again between the lines) the suggesting to change the behavior.
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."
That sounds like a great addition to the docs, except for the nit that I don't like writing the plural of NaN as "NaN's" -- I prefer "NaNs" myself. Also, the words here can still cause confusion. The exact behavior is that every one of the 6 comparison operators (==, !=, <, <=, >, >=) returns False when either argument (or both) is a NaN. I think your suggested words could lead someone to believe that they mean that x != NaN or NaN != Nan would return True.
Anyway, once we can agree to words I agree that we should update that section.
"In accordance with the IEEE 754 standard, when NaNs are compared to any value, even another NaN, the result is always False, regardless of the comparison. This is because NaN represents an unknown result. There is no way to know the relationship between an unknown result and any other result, especially another unknown one. Even comparing a NaN to itself always produces False."