On Sun, 24 Jul 2005, Aubrey Jaffer wrote:

> I had been interpreting this as applying to single operations; but, as
> Bear points out, the text could as well apply to composite
> calculations (in a compiled Scheme implementation).

Right.  And even if all single operations are within 1 ULP,
given a finite representation, composite operations cannot
be within 1 ULP in general.

> Changing the text to specify that "close as practical" applies to
> single procedure calls would allow positive ULP implementations to
> conform because the arithmetic operations are accurate and it would be
> impractical to bypass the other operations provided on many platforms.

> Implementations would not be prevented from optimizing mathematical
> expressions so long as the composite accuracy was as good or better
> than the procedure-wise "close as practical" accuracy.

> | Bear's suggestion that inexact numbers are simply results that
> | might be wrong would make no similar restriction on the accuracy of
> | these functions.

> | Do you agree with these conclusions?

>Changing the situation from "the result is probably wrong" to "the
>result is within n ULPs" would be a great improvement.  Does the
>procedure-wise-close-as-practical idea accomplish this?

Not unless you express N in terms of the number of
primitive operations in your composite operations, and
limit the composite operations to those that don't involve
what the Numerical Recipes book calls "catastrophic
roundoff."  Even so, I think N would vary with the
square of the number of multiplications.

				Bear