[Python-Dev] Why is nan != nan?
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
>>>> 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 2**53-2 different nans (2**52-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.
More information about the Python-Dev