Revision of SRFI 70 available Michael Sperber (18 Jul 2005 11:58 UTC)
Re: Revision of SRFI 70 available bear (18 Jul 2005 15:50 UTC)
inexactness vs. exactness Aubrey Jaffer (18 Jul 2005 23:57 UTC)
Re: inexactness vs. exactness bear (19 Jul 2005 02:31 UTC)
Re: inexactness vs. exactness Aubrey Jaffer (21 Jul 2005 17:01 UTC)
Re: inexactness vs. exactness bear (22 Jul 2005 00:22 UTC)
Re: inexactness vs. exactness Aubrey Jaffer (22 Jul 2005 16:01 UTC)
Re: inexactness vs. exactness bear (22 Jul 2005 16:21 UTC)
Re: inexactness vs. exactness Alan Watson (22 Jul 2005 18:21 UTC)
Re: inexactness vs. exactness Aubrey Jaffer (25 Jul 2005 03:38 UTC)
Re: inexactness vs. exactness bear (27 Jul 2005 16:03 UTC)

Re: inexactness vs. exactness Aubrey Jaffer 25 Jul 2005 03:38 UTC

 | Date: Fri, 22 Jul 2005 13:20:25 -0500
 | From: Alan Watson <xxxxxx@astrosmo.unam.mx>
 |
 | Your idea that inexacts respresent intervals is interesting.
 | However, consider a system that used IEEE doubles for inexacts but
 | implemented a certain transcendental function with several ULPs of
 | error.  If I use this function, I will not necesarily get the
 | inexact number that is closest to the exact result or, in other
 | words, I will not get the inexact number that corresponds to the
 | interval containing the exact result.

I thought that is why section 6.2.2 was worded:

  ... it is the duty of each implementation to make the result as
  close as practical to the mathematically ideal result.

rather than saying:

  The result will be the inexact number closest to the mathematically
  ideal result.

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).

The detailed proof I posted today was written to exploit the accuracy
requirement of STRING->NUMBER (which is stronger than
close-as-practical) to avoid this composite expression ambiguity.

 | So, it would seem that if we accept that inexacts are intervals, we
 | also force all of the transcendental functions to have 0 ULPs of
 | error.

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?