Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Tue, 31 May 2011 23:09:36 -0700 (PDT)
In-Reply-To: <mailman.2354.1306900680.9059.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=74.37.53.32; posting-account=XFEWnwoAAADNO10m3Wcmq_SWdmyZuXff
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: float("nan") in set or as key
From: Carl Banks <pavlovevidence@gmail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Reply-To: comp.lang.python@googlegroups.com
Message-ID: <mailman.2355.1306908579.9059.python-list@python.org>
Lines: 83
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:6788

On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks=20
>  wrote:
> > I think you misunderstood what I was saying.
> >
> > It's not *possible* to represent a real number abstractly in any digita=
l computer. =A0Python couldn't have an "abstract real number" type even it =
wanted to.
>=20
> True, but why should the "non-integer number" type be floating point
> rather than (say) rational?

Python has several non-integer number types in the standard library.  The o=
ne we are talking about is called float.  If the type we were talking about=
 had instead been called real, then your question might make some sense.  B=
ut the fact that it's called float really does imply that that underlying r=
epresentation is floating point.


> 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?

Once again, Python float is an IEEE double-precision floating point number.=
  This is part of the language; it is not an implementation detail.  As I m=
entioned elsewhere, the Python library establishes this as part of the lang=
uage because it includes several functions that operate on IEEE numbers.

And, by the way, the types you're comparing it to aren't as abstract as you=
 say they are.  Python's int type is required to have a two's-compliment bi=
nary representation and support bitwise operations.


> > (Math aside: Real numbers are not countable, meaning they=20
> > cannot be put into one-to-one correspondence with integers.
> > =A0A 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.)
>=20
> Right. Obviously a true 'real number' representation can't be done.
> But there are multiple plausible approximations thereof (the best
> being rationals).

That's a different question.  I don't care to discuss it, except to say tha=
t your default real-number type would have to be called something other tha=
n float, if it were not a floating point.


> 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.

It really isn't.  Unlike with characters (which are trivially extensible to=
 larger character sets, just add more bytes), different real number approxi=
mations differ in details too important to be left to the implementation.

For instance, say you are using an implementation that uses floating point,=
 and you define a function that uses Newton's method to find a square root:

def square_root(N,x=3DNone):
    if x is None:
        x =3D N/2
    for i in range(100):
        x =3D (x + N/x)/2
    return x

It works pretty well on your floating-point implementation.  Now try runnin=
g it on an implementation that uses fractions by default....

(Seriously, try running this function with N as a Fraction.)

So I'm going to opine that the representation does not seem like an impleme=
ntation detail.


Carl Banks