On Fri, 14 Oct 2005, Aubrey Jaffer wrote:

> What is the rationale for mandating exact rationals?  Over 15 years I
> have written numerical Scheme code for everything from symbolic
> algebra to Galois fields to linear systems to optics simulations
> without needing exact rationals.

Unlimited-precision rationals are absolutely irreplaceable  - when
they are exactly what a given application requires.  But that's mostly
number-theory and related domains, which isn't very common in practice.

In practice, what I've found is that unlimited-precision rationals
cause straightforward calculations to explode and take unlimited
memory space and time, unless you are careful to throw the appropriate
exact->inexact call in a critical place or remember to type a point
with the arguments that need to be inexact.

And, code written to *avoid* the use of unlimited-precision, which
is usually necessary, is (however trivially) more complicated than
code that uses it (or winds up using it even though it contributes
little, or negatively, to the code's utility).

I see newbies fall into the trap, too often; they write something
that should do a simple series expansion, and watch aghast as it
mysteriously consumes all available resources.  Or code that worked
fine on one scheme implementation explodes on a different one that
provides unlimited rationals, creating an unnecessary porting issue.

So I see it as having conflicting design principles:

    "Optimize the common or most useful case" generally means avoiding
    unlimited-precision calculations really shouldn't be something you
    have to think about.  Representation and operation times that
    expand toward infinity are anathema when you are optimizing -
    optimization forces you to regard numbers as representations on
    a (finite) physical computer with bounded processing power.

    "Numbers are independent of their representation and exact whenever
    possible" on the other hand says that rationals should be used
    by default, whenever possible. The fact that representation and
    time used quickly expand toward infinity in many common calculations
    is irrelevant to this principle which regards numbers as abstractions
    and code as merely a means for *expression* of algorithms.

Finding an appropriate compromise between these principles is at
best a ticklish business.  We don't want to cripple scheme for people
who actually need unlimited-precision rationals, but at the same time
we'd like to optimize the common case, meaning that in the course of
ordinary programming we shouldn't have to think about *avoiding*
unlimited-precision rationals.

				Bear