On 10/26/2012 11:26 AM, Steven D'Aprano wrote:
On Fri, 26 Oct 2012 03:54:02 -0400, Terry Reedy wrote:
On 10/25/2012 10:44 PM, Steven D'Aprano wrote:
On Thu, 25 Oct 2012 22:04:52 -0400, Terry Reedy wrote:
It is a consequence of the following, which some people (but not all)
believe is mandated by the IEEE standard.
>>> nan = float('nan')
>>> nan is nan
True
The IEEE 754 standard says nothing about object identity. It only
discusses value equality.
>>> nan == nan
False
IEEE 754 states that all NANs compare unequal to everything, including
NANs with the same bit value. It doesn't make an exception for
comparisons with itself.
I'm not entirely sure why you suggest that there is an argument about
what IEEE 754 says about NANs.
I did not do so.
I'm afraid you did. Your quote is shown above, and repeated here:
The quote precedes and refers to Python code.
"... some people (but not all) believe is mandated by the IEEE standard"
This suggests that there is a disagreement -- an argument -- about what
the IEEE standard mandates about NANs.
Disagreement about what Python should do has been expressed on the lists
and even on the tracker. There was one discussion on python-ideas within
the last month, another a year or so ago.
Python does not implement the full IEEE standard with signalling and
non-signalling nans and multiple bit patterns.
When a nan is put in a Python collection, it is in effect treated as if
it were equal to itself.
See the discussion in http://bugs.python.org/issue4296
including "I'm not sure that Python should be asked to guarantee
anything more than "b == b" returning False when b is
a NaN. It wouldn't seem unreasonable to consider
behavior of nans in containers (sets, lists, dicts)
as undefined when it comes to equality and identity
checks."
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
