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

Groups > comp.lang.python > #6779 > 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 20:30 -0700
    Re: float("nan") in set or as key Roy Smith <roy@panix.com> - 2011-05-31 23:43 -0400
      Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-06-01 14:04 +0000
    Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-06-01 13:57 +1000
      Re: float("nan") in set or as key Ben Finney <ben+python@benfinney.id.au> - 2011-06-01 15:18 +1000
    Re: float("nan") in set or as key Jerry Hill <malaclypse2@gmail.com> - 2011-06-01 09:44 -0400
    Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-06-02 02:12 +1000

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

On Tuesday, May 31, 2011 8:05:43 PM UTC-7, Chris Angelico wrote:
> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks 
>  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 think you misunderstood what I was saying.

It's not *possible* to represent a real number abstractly in any digital computer.  Python couldn't have an "abstract real number" type even it wanted to.

(Math aside: Real numbers are not countable, meaning they cannot be put into one-to-one correspondence with integers.  A digital computer can only represent countable things exactly, for obvious reasons; therefore, to model non-countable things like real numbers, one must use a countable approximation like floating-point.)

You might be able to get away with saying float() merely represents an "abstract floating-point number with provisions for nan and inf", but pretty much everyone uses IEEE format, so what's the point?  And no it doesn't mean Python has to support every nuance (and it doesn't).


Carl Banks

[toc] | [next] | [standalone]

#6782

In article 
Carl Banks <pavlovevidence@gmail.com> wrote:

> pretty much everyone uses IEEE format

Is there *any* hardware in use today which supports floating point using 
a format other than IEEE?

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

#6794

On 2011-06-01, Roy Smith <roy@panix.com> wrote:
> In article 
> Carl Banks <pavlovevidence@gmail.com> wrote:
>
>> pretty much everyone uses IEEE format
>
> Is there *any* hardware in use today which supports floating point using 
> a format other than IEEE?

Well, there are probably still some VAXes around in odd corners...

-- 
Grant Edwards               grant.b.edwards        Yow! Thank god!! ... It's
                                  at               HENNY YOUNGMAN!!
                              gmail.com            

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

#6784

On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks <pavlovevidence@gmail.com> wrote:
> I think you misunderstood what I was saying.
>
> It's not *possible* to represent a real number abstractly in any digital computer.  Python couldn't have an "abstract real number" type even it wanted to.

True, but why should the "non-integer number" type be floating point
rather than (say) rational? Actually, IEEE floating point could mostly
be implemented in a two-int rationals system (where the 'int' is
arbitrary precision, so it'd be Python 2's 'long' rather than its
'int'); in a sense, the mantissa is the numerator, and the scale
defines the denominator (which will always be a power of 2). Yes,
there are very good reasons for going with the current system. But are
those reasons part of the details of implementation, or are they part
of the definition of the data type?

> (Math aside: Real numbers are not countable, meaning they cannot be put into one-to-one correspondence with integers.  A digital computer can only represent countable things exactly, for obvious reasons; therefore, to model non-countable things like real numbers, one must use a countable approximation like floating-point.)

Right. Obviously a true 'real number' representation can't be done.
But there are multiple plausible approximations thereof (the best
being rationals).

Not asking for Python to be changed, just wondering why it's defined
by what looks like an implementation detail. It's like defining that a
'character' is an 8-bit number using the ASCII system, which then
becomes problematic with Unicode. (Ohai, C, didn't notice you standing
there.)

Chris Angelico

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

#6786

Chris Angelico <rosuav@gmail.com> writes:

> Right. Obviously a true 'real number' representation can't be done.
> But there are multiple plausible approximations thereof (the best
> being rationals).

Sure. But most of those are not what is most commonly meant by ‘float’
type.

> Not asking for Python to be changed, just wondering why it's defined
> by what looks like an implementation detail.

Because, in the case of the ‘float’ type, the agreed-upon meaning of
that type – in Python as in just about every other language that is
well-specified – is “an IEEE float as per the IEEE 754 spec”.

A foolish consistency to the spec would be a hobgoblin for little minds.
But, given that a ‘float’ type which deviated from that spec would just
be inviting all sorts of other confusion, it's not a foolish
consistency.

> It's like defining that a 'character' is an 8-bit number using the
> ASCII system, which then becomes problematic with Unicode.

Right. That's why in Python 3 the Unicode text type is called ‘unicode’,
the IEEE float type is called ‘float’, and the byte string type is
called ‘bytes’.

It's also why the ‘str’ type in Python 2 was painful enough to need
changing: it didn't clearly stick to a specification, but tried to
straddle the worlds between one specification (a text type) and an
incompatible other specification (a bytes sequence type).

Where there is a clearly-defined widely-agreed specification for a type,
it's a good idea to stick to that specification when claiming to
implement that functionality in a type.

-- 
 \       “The man who is denied the opportunity of taking decisions of |
  `\      importance begins to regard as important the decisions he is |
_o__)                        allowed to take.” —C. Northcote Parkinson |
Ben Finney

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

#6792

> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks <pavlovevidence@gmail.com> wrote:
> True, but why should the "non-integer number" type be floating point
> rather than (say) rational?

You seem to be implying that python only provides a single non-integer
numeric type.  That's not true.  Python ships with a bunch of
different numeric types, including a rational type.  Off the top of my
head, we have:

IEEE floating point numbers
(http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex)
Rationals (http://docs.python.org/library/fractions.html)
Base-10 fixed and floating point numbers
(http://docs.python.org/library/decimal.html)
Complex numbers
(http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex
plus http://docs.python.org/library/cmath.html)
Integers (both ints and longs, which are pretty well unified by now)

Floats have far and away the best performance in most common
situations, so they end up being the default, but if you want to use
something different, it's usually not hard to do.

-- 
Jerry

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

#6797

On Wed, Jun 1, 2011 at 11:44 PM, Jerry Hill <malaclypse2@gmail.com> wrote:
>> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks <pavlovevidence@gmail.com> wrote:
>> True, but why should the "non-integer number" type be floating point
>> rather than (say) rational?

Careful with the attributions, Carl was quoting me when he posted that :)

> You seem to be implying that python only provides a single non-integer
> numeric type.  That's not true.  Python ships with a bunch of
> different numeric types, including a rational type.  Off the top of my
> head, we have:
>
> IEEE floating point numbers
> (http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex)
> Rationals (http://docs.python.org/library/fractions.html)
> Base-10 fixed and floating point numbers
> (http://docs.python.org/library/decimal.html)
> Complex numbers
> (http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex
> plus http://docs.python.org/library/cmath.html)
> Integers (both ints and longs, which are pretty well unified by now)

I know Python does support all of the above. Leave off int/long and
complex, which are obviously not trying to store real numbers
(although I guess you could conceivably make 'complex' the vehicle for
reals too), there's three: float, fraction, decimal. Of them, one is a
built-in type and the other two are imported modules. Hence my
question about why this one and not that one should be the "default"
that people will naturally turn to as soon as they need non-integers.
(Or, phrasing it another way: Only one of them is the type that "3.2"
in your source code will be represented as.)

> Floats have far and away the best performance in most common
> situations, so they end up being the default, but if you want to use
> something different, it's usually not hard to do.

And that, right there, is the answer.

ChrisA

[toc] | [prev] | [standalone]

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

csiph-web