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

Groups > comp.lang.python > #6776 > 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-31 19:59 -0700
    Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-06-01 13:05 +1000
      Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-06-01 14:03 +0000
        Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-02 01:10 +0000

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

On Sunday, May 29, 2011 7:53:59 PM UTC-7, 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", or "a Python representation of a real number"?

The former.  Unlike the case with integers, there is no way that I know of to represent an abstract real number on a digital computer.

Python also includes several IEEE-defined operations in its library (math.isnan, math.frexp).


Carl Banks

[toc] | [next] | [standalone]

#6777

On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks <pavlovevidence@gmail.com> wrote:
> On Sunday, May 29, 2011 7:53:59 PM UTC-7, 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", or "a Python representation of a real number"?
>
> The former.  Unlike the case with integers, there is no way that I know of to represent an abstract real number on a digital computer.

This seems peculiar. Normally Python seeks to define its data types in
the abstract and then leave the concrete up to the various
implementations - note, for instance, how Python 3 has dispensed with
'int' vs 'long' and just made a single 'int' type that can hold any
integer. Does this mean that an implementation of Python on hardware
that has some other type of floating point must simulate IEEE
double-precision in all its nuances?

I'm glad I don't often need floating point numbers. They can be so annoying!

Chris Angelico

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

#6793

On 2011-06-01, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks <pavlovevidence@gmail.com> wrote:
>> On Sunday, May 29, 2011 7:53:59 PM UTC-7, 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", or "a Python representation of a real number"?
>>
>> The former. ?Unlike the case with integers, there is no way that I know of to represent an abstract real number on a digital computer.
>
> This seems peculiar. Normally Python seeks to define its data types
> in the abstract and then leave the concrete up to the various
> implementations - note,

But, "real numbers" and "IEEE float" are so different that I don't
think that it would be a wise decision for people to pretend they're
working with real numbers when in fact they are working with IEEE
floats.

> for instance, how Python 3 has dispensed with 'int' vs 'long' and
> just made a single 'int' type that can hold any integer.

Those concepts are much closer than "real numbers" and "IEEE floats".

> Does this mean that an implementation of Python on hardware that has
> some other type of floating point must simulate IEEE double-precision
> in all its nuances?

I certainly hope so.  I depend on things like propogation of
non-signalling nans, the behavior of infinities, etc.

> I'm glad I don't often need floating point numbers. They can be so
> annoying!

They can be -- especially if one pretends one is working with real
numbers instead of fixed-length binary floating point numbers.  Like
any tool, floating point has to be used properly. Screwdrivers make
very annoying hammers.

-- 
Grant Edwards               grant.b.edwards        Yow! How's it going in
                                  at               those MODULAR LOVE UNITS??
                              gmail.com            

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

#6833

On Wed, 01 Jun 2011 14:03:14 +0000, Grant Edwards wrote:

> On 2011-06-01, Chris Angelico <rosuav@gmail.com> wrote:
>> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks <pavlovevidence@gmail.com>
>> wrote:
>>> On Sunday, May 29, 2011 7:53:59 PM UTC-7, 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", or "a Python representation of a real number"?
>>>
>>> The former. ?Unlike the case with integers, there is no way that I
>>> know of to represent an abstract real number on a digital computer.
>>
>> This seems peculiar. Normally Python seeks to define its data types in
>> the abstract and then leave the concrete up to the various
>> implementations - note,
> 
> But, "real numbers" and "IEEE float" are so different that I don't think
> that it would be a wise decision for people to pretend they're working
> with real numbers when in fact they are working with IEEE floats.

People pretend that *all the time*.

Much of the opposition to NANs, for example, is that it violates 
properties of the reals. But so do ordinary floats! People just pretend 
otherwise.

For reals, a + b - a = b, always without exception. For floats, not so 
much.

For reals, a*(b + c) = a*b + a*c, always without exception. For floats, 
not so much.

For reals, 1/(1/x) = x, except for 0, always. For floats, not so much. 
For IEEE floats with proper support for INF, 0 is one of the cases which 
does work!

These sorts of violations are far more likely to bite you than the NAN 
boogey, that x != x when x is a NAN. But people go into paroxysms of 
concern over the violation that they will probably never see, and ignore 
the dozens that they trip over day after day.

Compiler optimizations are some of the worst and most egregious 
violations of the rule Floats Are Not Reals. Large numbers of numeric 
algorithms are simply broken due to invalid optimizations written by C 
programmers who think that because they have a high school understanding 
of real-value math they therefore understand floats.


-- 
Steven

[toc] | [prev] | [standalone]

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

csiph-web