Why isn't Python king of the hill?

[Tim Peters]

[Geoffrey Gerrietts]
> ...
> Rational numbers are tracked as a numerator and denominator, nothing
> more complicated than that. The danger with rational numbers is that
> they require a lot of storage space, and that the integers involved
> sometimes get really, really big.

They *can*, and that can make them as surprising to newbies as anything
else.  OTOH, sometimes they don't <wink>.  For example, let's imagine a
hypothetical Python using rational arithmetic, and a newbie computing

sum = 0
for i in range(1, 101):
    sum += 1/i

It can be very surprising at first that the result is

    14466636279520351160221518043104131447711
    -----------------------------------------
     2788815009188499086581352357412492142272

In floating-point instead they'd get

    5.1873775176396206

and much quicker.  OTOH, it may be years before they learn (and perhaps "the
hard way") that adding the reciprocals from largest to smallest is
numerically worse than adding them in the other direction under f.p. (and
whether binary or decimal) -- but it doesn't matter at all under rationals.

On the third hand, if you're just adding dollars-and-cents things under a
rational system, all the denominators are the same and then nothing "gets
real big" under the covers (the denominator of the final result won't be
larger than 100).

Unfortunately, *all* finite representations of reals suffer surprises, some
gross, some subtle.  If you have more than one choice, you need some amount
of expertise to choose wisely, and no single system is best for all
purposes.

> I'm told that you can't reasonably limit the size of the integers,
> either, because if you do, your accuracy will suffer even worse
> than if you'd stuck to floats.

Eh -- highly debatable.  Much work has been done on so-called "floating
slash" (or "flash") systems, but they still have a specialized audience.  If
there are physical reasons to suspect the true results are relatively simple
fractions, they can beat the accuracy pants off of f.p.  But for newbies
they (IMO) combine the worst of all worlds:  exact results in simple cases,
but "suddenly and for no reason at all" <wink> inexact results creep in
without warning.

> I guess that means that asking for the answer to exactly the right
> question could result in a single absolutely enormous number, and
> it could take a very long time to arrive at that number.

This was a common newbie experience in ABC (a language Guido worked on
before Python, where all arithmetic was rational by default).  In "serious
work", just as experts need to keep track of worst-case error bounds in f.p.
arithmetic, when using rational arithmetic for problems where exact results
aren't required, experts need to keep track of worst-case *size* bounds and
explicitly round back at appropriate points to keep computation time
tractable.

a-fast-answer-is-useless-if-it's-wrong-but-an-exact-answer-is-useless-
    if-you-can't-get-it-by-the-time-it's-needed-ly y'rs  - tim