| Date: Sat, 30 Jul 2005 23:20:08 -0700 (PDT)
 | From: bear <xxxxxx@sonic.net>
 |
 | I know that it's not the right thing in all cases and all times,
 | but I think it's a good thing in most of the cases I use, for
 | an operation on exact arguments whose mathematically correct
 | result is too large to be represented as an exact number, to
 | (silently) return an inexact number of the highest available
 | precision.
 |
 | Thus, precision escalating out of control in an iterative
 | algorithm using rationals eventually breaks a point where
 | the denominator is more than three hundred digits long,
 | and instead of crashing or bogging down with ever-larger
 | diophantine fractional calculations, and an addition or
 | a multiplication or whatever returns a float.

There is a third way: report a violation of an implementation
restriction when trying to return numbers with more than, say, 16000
bits.  Practical calculation on numbers larger than that would need
FFT multiplication and other number-theoretic algorithms, which is a
lot of hair to support execution of simple programming errors.

 | This behavior is neither mandated nor forbidden by R5RS.  I
 | think that's a good thing.  Your proposal also does not
 | mandate nor forbid it; I think that's a good thing too. But
 | it sounds like you came really close to forbidding it, and
 | may have failed to do so only by accident.  So I just wanted
 | to point it out as a frequently desirable behavior.

The sentence:

  For exact numbers, it is the programmer's responsibility to avoid
  using numbers with magnitude or precision too large to be
  represented in the implementation.

was adapted from W. Clinger's comments, which I believe were referring
to R5RS.  The purpose for including it was to clarify the situation,
not to make new law.  Do I misunderstand?

Section 6.2.2 Exactness as I am working on it is appended:

			      -=-=-=-=-

 | 6.2.2 Exactness

 | Scheme numbers are either exact or inexact.  A number is exact if
 | it was written as an exact constant or was derived from exact
 | numbers using only exact operations.  A number is inexact
if it is infinite,
 | if it was written as an inexact constant, if it was derived using
 | inexact ingredients, or if it was derived using inexact operations.
 | Thus inexactness is a contagious property of a number.

Each exact number corresponds to a single mathematical number.  For
exact numbers, it is the programmer's responsibility to avoid using
numbers with magnitude or precision too large to be represented in the
implementation.

Inexact numbers are approximate.  Every mathematical number within the
(convex) range of inexacts supported by an implementation will round
to an inexact number on input or as a result of computation.  The
neighborhood of mathematical numbers rounding to a particular inexact
number must be simply connected.

Because real infinities are mandated (in implementations supporting
inexacts), all mathematical real numbers map to inexact numbers.  For
non-real complex numbers, it is the programmer's responsibility to
avoid using numbers with magnitude too large to be represented in the
implementation.

 | If two implementations produce exact results for a computation that
 | did not involve inexact intermediate results, the two ultimate
 | results will be mathematically equivalent.  This is not true of
 | computations involving inexact numbers because approximate methods
 | such as floating point arithmetic may be used, but it is the duty
 | of each implementation to make the result as close as practical to
 | the mathematically ideal result.

 | Rational operations such as `+' should always produce exact results
 | when given exact arguments.  If the operation is unable to produce
 | an exact result, then it may either report the violation of an
 | implementation restriction or it may silently coerce its result to
 | an inexact value.  See section 6.2.3 Implementation restrictions.

 | With the exception of inexact->exact,
`round->exact', `ceiling->exact', `floor->exact', and `truncate->exact',
 | the operations described in this section must return
 | inexact results when given any inexact arguments.