[Python-Dev] Why is nan != nan? (original) (raw)

Mark Dickinson 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:

http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ 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. :)

Mark

More information about the Python-Dev mailing list