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

Tim Peters tim@zope.com
Fri, 4 Oct 2002 13:36:59 -0400


[M.-A. Lemburg]
> ...
> But isn't division much more costly than addition and multiplication
> if you have long integers to deal with ? (I can't tell, because the
> works are done by GMP in mxNumber)

There's no real bound on how large partial quotients can get, and rationals
can grow extremely large.  Dividing once to get, e.g., 10000, is enormously
cheaper than going around a Python loop 10000 times, and creating and
destroying several times that many temporary longs, just to avoid one
relatively fast C-speed longint division with a small quotient.

It's essentially the same as figuring out "the fastest" way to code a gcd,
and that's a very tricky problem at the Python level.  Partial quotients are
*usually* 1, and then subtraction is cheaper, and it's also possible to meld
both approaches to exploit that.

> ...
> How useful are .trim() and .approximate() in practice ?

You're going to get as many responses to that as Guido got to his query
about how mxNumber users like its type hierarchy <wink>.

> If they are, then I could put them on the TODO list for mxNumber.

They're useful for people who want to mix rationals with approximation, and
that's an unlikely intersection outside of expert use.  _trim is essentially
what fixed-slash and floating-slash arithmetics use under the covers to keep
rigorous bounds on memory use, in exchange for losing information.  How
useful is that in practice?  Beats me; it depends so much on whose practice
we're talking about <wink>.