Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6611 > unrolled thread

Re: float("nan") in set or as key

Back to article view | Back to comp.lang.python

Contents

  Re: float("nan") in set or as key Carl Banks <pavlovevidence@gmail.com> - 2011-05-29 19:17 -0700
    Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-05-30 12:53 +1000
      Re: float("nan") in set or as key rusi <rustompmody@gmail.com> - 2011-05-29 20:08 -0700
      Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-30 04:22 +0000

#6611 — Re: float("nan") in set or as key

On Sunday, May 29, 2011 6:14:58 PM UTC-7, Chris Angelico wrote:
> On Mon, May 30, 2011 at 10:55 AM, Carl Banks 
>  wrote:
> > If exceptions had commonly existed in that environment there's no chance they would have chosen that behavior; comparison against NaN (or any operation with NaN) would have signaled a floating point exception.  That is the correct way to handle exceptional conditions.
> >
> > The only reason to keep NaN's current behavior is to adhere to IEEE,
> > but given that Python has trailblazed a path of correcting arcane
> > mathematical behavior, I definitely see an argument that Python
> > should do the same for NaN, and if it were done Python would be a
> > better language.
> 
> If you're going to change behaviour, why have a floating point value
> called "nan" at all?

If I were designing a new floating-point standard for hardware, I would consider getting rid of NaN.  However, with the floating point standard that exists, that almost all floating point hardware mostly conforms to, there are certain bit pattern that mean NaN.

Python could refuse to construct float() objects out of NaN (I doubt it would even be a major performance penalty), but there's reasons why you wouldn't, the main one being to interface with other code that does use NaN.  It's better, then, to recognize the NaN bit patterns and do something reasonable when trying to operate on it.


Carl Banks

[toc] | [next] | [standalone]

#6614

On Mon, May 30, 2011 at 12:17 PM, Carl Banks <pavlovevidence@gmail.com> wrote:
> If I were designing a new floating-point standard for hardware, I would consider getting rid of NaN.  However, with the floating point standard that exists, that almost all floating point hardware mostly conforms to, there are certain bit pattern that mean NaN.
>
> Python could refuse to construct float() objects out of NaN (I doubt it would even be a major performance penalty), but there's reasons why you wouldn't, the main one being to interface with other code that does use NaN.  It's better, then, to recognize the NaN bit patterns and do something reasonable when trying to operate on it.

Okay, here's a question. The Python 'float' value - is it meant to be
"a Python representation of an IEEE double-precision floating point
value", or "a Python representation of a real number"? For the most
part, Python's data types are defined by their abstract concepts - a
list isn't defined as a linked list of pointers, it's defined as an
ordered collection of objects. Python 3 removes the distinction
between 'int' and 'long', where 'int' is <2**32 and 'long' isn't, so
now a Py3 integer is... any integer.

The sys.float_info struct exposes details of floating point
representation. In theory, a Python implementation that uses bignum
floats could quite happily set all those values to extremes and work
with enormous precision (or could use a REXX-style "numeric digits
100" command to change the internal rounding, and automatically update
sys.float_info). And in that case, there would be no NaN value.

If Python is interfacing with some other code that uses NaN, that code
won't be using Python 'float' objects - it'll be using IEEE binary
format, probably. So all it would need to entail is a special return
value from an IEEE Binary to Python Float converter function (maybe
have it return None), and NaN is no longer a part of Python.

The real question is: Would NaN's removal be beneficial? And if so,
would it be worth the effort?

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#6615

On May 30, 7:53 am, Chris Angelico <ros...@gmail.com> wrote:
> On Mon, May 30, 2011 at 12:17 PM, Carl Banks <pavlovevide...@gmail.com> wrote:
> > If I were designing a new floating-point standard for hardware, I would consider getting rid of NaN.  However, with the floating point standard that exists, that almost all floating point hardware mostly conforms to, there are certain bit pattern that mean NaN.
>
> > Python could refuse to construct float() objects out of NaN (I doubt it would even be a major performance penalty), but there's reasons why you wouldn't, the main one being to interface with other code that does use NaN.  It's better, then, to recognize the NaN bit patterns and do something reasonable when trying to operate on it.
>
> Okay, here's a question. The Python 'float' value - is it meant to be
> "a Python representation of an IEEE double-precision floating point
> value", or "a Python representation of a real number"? For the most
> part, Python's data types are defined by their abstract concepts - a
> list isn't defined as a linked list of pointers, it's defined as an
> ordered collection of objects. Python 3 removes the distinction
> between 'int' and 'long', where 'int' is <2**32 and 'long' isn't, so
> now a Py3 integer is... any integer.
>
> The sys.float_info struct exposes details of floating point
> representation. In theory, a Python implementation that uses bignum
> floats could quite happily set all those values to extremes and work
> with enormous precision (or could use a REXX-style "numeric digits
> 100" command to change the internal rounding, and automatically update
> sys.float_info). And in that case, there would be no NaN value.
>
> If Python is interfacing with some other code that uses NaN, that code
> won't be using Python 'float' objects - it'll be using IEEE binary
> format, probably. So all it would need to entail is a special return
> value from an IEEE Binary to Python Float converter function (maybe
> have it return None), and NaN is no longer a part of Python.
>
> The real question is: Would NaN's removal be beneficial? And if so,
> would it be worth the effort?
>
> Chris Angelico

nan in floating point is like null in databases
It may be worthwhile to have a look at what choices SQL has made
http://en.wikipedia.org/wiki/Null_%28SQL%29

[toc] | [prev] | [next] | [standalone]

#6620

On Mon, 30 May 2011 12:53:59 +1000, Chris Angelico wrote:

> Okay, here's a question. The Python 'float' value - is it meant to be "a
> Python representation of an IEEE double-precision floating point value",

Yes.

> or "a Python representation of a real number"? 

No.

Floats are not real numbers. Many fundamental properties of the reals are 
violated by floats, and I'm not talking about "weird" things like NANs 
and INFs, but ordinary numbers:

>>> a, b = 0.1, 0.7
>>> a + b - b == a
False



> For the most part,
> Python's data types are defined by their abstract concepts - a list
> isn't defined as a linked list of pointers, 

Nor is it implemented as a linked list of pointers.


> The sys.float_info struct exposes details of floating point
> representation. In theory, a Python implementation that uses bignum
> floats could quite happily set all those values to extremes and work
> with enormous precision (or could use a REXX-style "numeric digits 100"
> command to change the internal rounding, and automatically update
> sys.float_info). And in that case, there would be no NaN value.

NANs aren't for overflow, that's what INFs are for. Even if you had 
infinite precision floats and could get rid of INFs, you would still need 
NANs.


> The real question is: Would NaN's removal be beneficial? 

No, it would be another step backwards to the bad old days before the 
IEEE standard.




-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web