[Python-Dev] Why is nan != nan?
dickinsm at gmail.com
Thu Mar 25 12:55:57 CET 2010
On Thu, Mar 25, 2010 at 11:22 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Mark Dickinson wrote:
>> Here's an interesting recent blog post on this subject, from the
>> creator of Eiffel:
> Interesting. So the natural tweak that would arise from that perspective
> is for us to restore reflexivity by declaring that any given NaN is
> equal to *itself* but not to any other NaN (even one with the same payload).
> With NaN (in general) not being interned, that would actually fit the
> idea of a NaN implicitly carrying the operation that created the NaN as
> part of its definition of equivalence.
> So, I'm specifically putting that proposal on the table for both float
> and Decimal NaNs in Python:
> "Not a Number" is not a single floating point value. Instead each
> instance is a distinct value representing the precise conditions that
> created it. Thus, two "NaN" values x and y will compare equal iff they
> are the exact same NaN object (i.e. "if isnan(x) then x == y iff
> x is y".
In other words, this would make explicit, at the level of ==, what
Python's already doing under the hood (e.g. in
PyObjectRichCompareBool) for membership testing---at least for nans.
> As stated above, such a change would allow us to restore reflexivity
> (eliminating a bunch of weirdness) while still honouring the idea of NaN
> being a set of values rather than a single value.
+0.2 from me. I could happily live with this change; but could also
equally live with the existing weirdness.
It's still a little odd for an immutable type to care about object
identity, but I guess oddness comes with the floating-point territory.
More information about the Python-Dev