PEP239 (Rational Numbers) Reference Implementation and new issues

Chris Gonnerman chris.gonnerman at newcenturycomputers.net
Thu Oct 3 05:28:48 CEST 2002


<< apologies... I can't puzzle out some of the >>
<< quoting below, so I've removed the names to >>
<< make it fair.                               >>

----- Original Message ----- 
From: "Christian Tismer" <tismer at tismer.com>

> > 1) Should future division return rationals rather than 
> > floats.
> > 
> > >+1 for returning rationals.  It's the right thing -- and 
> > >if it fails, 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 
> > numerator and denominator of the fraction taken in 
> > isolation, not the number itself.

> > Consider inversions of an integer matrices, 
> > approximations with truncated 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.

Practicality beats purity.

If you don't believe me:

    >>> import this
    The Zen of Python, by Tim Peters

    << hack >>
    Although practicality beats purity.
    << hack >>

Yeah, I'm the one who has been arguing in favor of a
decimal arithmetic type in the standard library.  Ask 
me to support rationals in the standard library, and I'll
back you up.  Heck, I'll even accept (optional) rational
literals, like the way we do longs.  (As long as you 
support (optional) decimal literals in return... :-)

But I don't want to see rationals if I haven't asked for
them.  I'm sure nobody wants to see decimals if they
haven't asked for them, either.  Principle of least
surprise... if a program I wrote for an earlier version
suddenly starts taking much, much longer to run (maybe
worse: much, much longer *sometimes*), it may cost me a
lot of time to fix it up.

I agree, 

    1/3

is pretty nice as a rational literal; but would it hurt 
so much to say 

    1/3R

instead?

Chris Gonnerman -- chris.gonnerman at newcenturycomputers.net
http://newcenturycomputers.net





More information about the Python-list mailing list