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

Georg Brandl g.brandl at gmx.net
Thu Mar 25 07:54:39 CET 2010

Am 24.03.2010 22:47, schrieb Mark Dickinson:

On Wed, Mar 24, 2010 at 10:36 PM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:

On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson <dickinsm at gmail.com> wrote: ..

Neither is necessary, because Python doesn't actually use == as the equivalence relation for containment testing: the actual equivalence relation is: x equivalent to y iff id(x) == id(y) or x == y. This restores the missing reflexivity (besides being a useful optimization).

No, it does not:

float('nan') in [float('nan')] False Sure, but just think of it as having two different nans there. (You could imagine thinking of the id of the nan as part of the payload.)

That's interesting. Thinking of each value created by float('nan') as a different nan makes sense to my naive mind, and it also explains nicely the behavior present right now. Each nan comes from a different operation and therefore is a "different" non-number.

Of course, float being an immutable type, there is some reason to expect that all values created by float('nan') should be identical, but after all, datetime is an immutable type as well, but you wouldn't expect

datetime.now() in [datetime.now()]

to be true. The only wart left is that you can't distinguish different nans by their string representation -- this could be remedied by making it "nan-%s" % id(self), but that looks a bit ugly to me.

Georg

More information about the Python-Dev mailing list