[Python-Dev] Why is nan != nan?
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