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"?

If that phrase were interpreted as referring to the error
bounds for IEEE binary floating point arithmetic, say, then
most implementations of programming languages on Pentium
hardware would fail the test.  More surprisingly, they would
fail the test because they are following a sound recommendation
made by William Kahan and others: use the Pentium's extended
precision arithmetic whenever possible, even when the ultimate
result of the calculation will be represented in double
precision.

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.

For examples of this problem, use Google to search for
"floating point arithmetic"+"double rounding".

I think it would be a mistake to specify error bounds so
tightly as to rule out substitution of extended precision
for double precision.

Will