On 3/25/2010 8:13 AM, Mark Dickinson wrote:
On Thu, Mar 25, 2010 at 3:05 PM, Nick Coghlan<ncogh...@gmail.com> wrote:
Mark Dickinson wrote:
On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan<ncogh...@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 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.
Glenn
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
