This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
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