| From: William D Clinger <xxxxxx@ccs.neu.edu>
 | Date: Sun, 31 Jul 2005 20:35:41 -0400
 |
 | Aubrey Jaffer wrote:
 | > My current thinking is to modify SRFI-70 to incorporate this
 | > distinction between exact and inexact:
 |
 | The last paragraph of his proposed wording ran as follows:
 |
 | >   It is the duty of each implementation to make the result of
 | >   mathematical expressions as close as practical to the
 | >   mathematically ideal result.  The error in results of optimized
 | >   or compiled mathematical expressions must be no larger than the
 | >   error band expected from the combination of the error bands of
 | >   its component operations.
 |
 | That last sentence goes to the brink of a precipice, if not
 | beyond.  What is meant by "expected from the combination of
 | the error bands of its component operations"?

The idea was that if each operation were executed by a separate
procedure call, then the precision of results executed in aggregated
code would not be worse.

 | ...
 | Most of the time, extended precision improves the accuracy
 | of a sequence of arithmetic operations.  Every once in a
 | while, however, the use of extended precision *reduces*
 | the accuracy compared to the use of double precision for
 | the same sequence of operations.  Furthermore the reduced
 | accuracy can make the error of the calculation in extended
 | precision larger in magnitude than the error that is allowed
 | for the corresponding double precision calculation.

Okay.  I will remove the second sentence.

			       -=-=-=-

With the range of number representations we have been discussing, some
of "6.2.3 Implementation restrictions" is seeming poorly specified:

  If, however, an exact number is operated upon so as to produce an
  inexact result (as by `sqrt'), and if the result is represented as a
  flonum, then the most precise flonum format available must be used;

  but if the result is represented in some other way then the
  representation must have at least as much precision as the most
  precise flonum format available.

The second half is a strong statement; why are flonums specifically
called out in the first half?

And specifically which representations are "flonums"?

The only definition R5RS gives for flonums is "Machine representations
such as fixed point and floating point are referred to by names such
as fixnum and flonum."

Would floating-point numbers with latent explicit precision be
flonums?

Such a representation may well support arbitrary precision; in which
case the term "most precise flonum format available" is not
well-defined for the implementation.