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

Glenn Linderman v+python at g.nevcal.com
Thu Mar 25 20:31:28 CET 2010

On 3/25/2010 8:13 AM, Mark Dickinson wrote:

On Thu, Mar 25, 2010 at 3:05 PM, Nick Coghlan<ncoghlan at gmail.com> wrote:

Mark Dickinson wrote:

On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan<ncoghlan at gmail.com> wrote:

Jesus Cea wrote:

But IEEE 754 was created by pretty clever guys and sure they had a reason for define things in the way they are. Probably we are missing something. Yes, this is where their "implementable in a hardware circuit" focus comes in. They were primarily thinking of a floating point representation where the 32/64 bits are it - you can't have "multiple NaNs" because you don't have the bits available to describe them. I'm not so sure about this: standard 64-bit binary IEEE 754 doubles allow for 253-2 different nans (252-2 signaling nans, 2**52 quiet nans): anything with bit pattern (msb to lsb) x1111111 1111xxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx is an infinity or a nan, and there are only 2 infinities. I stand corrected :) It still seems to me that the problems mostly arise when we're trying to get floats and Decimals to behave like Python objects (i.e. with reflexive equality) rather than like IEEE defined numbers. It's an extra element that isn't part of the problem the numeric standards are trying to solve. Agreed. We don't have to be "missing something"; rather, the IEEE folks (quite understandably) almost certainly didn't anticipate this kind of usage. So I'll concede that it's reasonable to consider deviating from the standard in the light of this.

It is my understand that even bit-for-bit identical NaN values will compare unequal according to IEEE 754 rules.

I would have no problem with Python interning each encountered NaN value, to avoid having bit-for-bit identical NaN values with different Python IDs, but having them compare equal seems inappropriate.

Glenn

More information about the Python-Dev mailing list