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

Alexander Belopolsky alexander.belopolsky at gmail.com
Wed Mar 24 22:31:57 CET 2010

On Wed, Mar 24, 2010 at 3:26 PM, Mark Dickinson <dickinsm at gmail.com> 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/

It appears that Meyer's view has evolved over the years:

""" In this context it doesn't particularly shock me that operations on NaN should cause invariant violations. After all, isn't NaN supposed to mean "not a number"? If it's not a number, it doesn't have to satisfy the properties of numbers. """ "NaN and floating point exceptions" by Roger Browne quoting an ISE Eiffel mailing list post by Bertrand Meyer

http://teameiffel.blogspot.com/2006/04/nan-and-floating-point-exceptions.html

Compare this with the conclusion he reached in "Pillars:"

"It is rather dangerous indeed to depart from the fundamental laws of mathematics. "

To bring the discussion back on topic for python-dev, I would argue that reflexivity should hold for hashable values. Having it otherwise would lead to unsurmountable problems when storing such values in sets or using them as keys in dictionaries. If x == x is False stays for x = float('nan'), I would argue that hash(float('nan')) should raise NotImplemented or ValueError.

More information about the Python-Dev mailing list