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