[Python-Dev] Re: PEP239 (Rational Numbers) Reference Implementation and new issues

[Christian Tismer]

Fran=E7ois Pinard wrote:
> [Eric S. Raymond]
>=20
>=20
>>>1) Should future division return rationals rather than floats.
>>
>=20
>>+1 for returning rationals.  It's the right thing -- and if it fails,=20
>>it will fail noisily, right?

+1 here, too!

> While I agree with the theoretical arguments, I have the practical fear=
 that
> rationals could grow very big, rather quickly, in the course of a long
> computation involving them in various ways.  By big, I mean the numerat=
or
> and denominator of the fraction taken in isolation, not the number itse=
lf.
> Consider inversions of an integer matrices, approximations with truncat=
ed
> series, or worse things like, maybe, discrete Fourier transforms.

Yes, this fear is right.
I think this is just great. Let it grow! Let the user feel what
precision he's carrying around, and how much they throw away
when they reduce down to float.

No I think this is really of advantage. Exact is better than small,
and it is all in the user's hand. Make a float() and you're done.

> Bigger rationals are, slower they become, and more memory they take.  T=
he
> danger is that programmers may get surprised or hurt by Python performa=
nce
> degradation, raising frequent and recurrent questions here and elsewher=
e.
>=20
> On the other hand, I would love if Python was not loosing precision on
> non-truncating integer division, so let me try a bit to destroy my own
> fears.  On average, most programs will not use matrices of rational num=
bers,
> nor play with series.  Moreover, most programs do not use so many diffe=
rent
> numeric variables anyway, nor perform long computations involving them.
> Many programs do not go beyond adding or subtracting one, once in a whi=
le!

I don't think one was considering to go rationale, all the time,
just as the result of integer divide? To me, rationales would be
the natural superclass of integers.
Floats would stand somewhere else, really different animals.

> So, I would guess that _on the average_, using rational numbers might b=
e
> acceptable and go almost unnoticed by most people.  So it might be more
> worth accepting as a community to warn programmers who are more prone t=
o
> numerical algorithms of the intrinsic dangers of integer division in Py=
thon.
>=20
> But those feelings are no proof of anything.  How do we get the confirm=
ation
> that using rationals in Python would be easy going and innocuous in
> practice, beforehand?  It would surely be nice relying in such a featur=
e!

I'm all for it. Get correct results in the first place.
Cut precision explicitly when needed, or for optimization.

BTW., Mathematica did the same thing. Very handy if you are doing
symbolic operations on polynomials, and you can easily keep
exact coefficients for a long time.
Another point is that a long division would never give an overflow.
Overflow since floats are too limited is an effect I don't find funny.

ciao - chris

--=20
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/