[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: a.watson@xxxxxxxxxxxxxxxx*Subject*: Re: inexactness vs. exactness*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Sun, 24 Jul 2005 23:38:19 -0400 (EDT)*Cc*: bear@xxxxxxxxx, srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <42E138E9.90609@xxxxxxxxxxxxxxxx> (message from Alan Watson on Fri, 22 Jul 2005 13:20:25 -0500)*References*: <y9lvf38ba3a.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0507180818240.7111@xxxxxxxxxxxxxx> <20050718235825.0D1381B77B4@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0507181844440.8883@xxxxxxxxxxxxxx> <20050721170155.F3A021B77B4@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0507211712001.849@xxxxxxxxxxxxxx> <20050722160214.4A9281B77B4@xxxxxxxxxxxxxxxx> <42E138E9.90609@xxxxxxxxxxxxxxxx>

| Date: Fri, 22 Jul 2005 13:20:25 -0500 | From: Alan Watson <a.watson@xxxxxxxxxxxxxxxx> | | 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?

**Follow-Ups**:**Re: inexactness vs. exactness***From:*bear

**References**:**Revision of SRFI 70 available***From:*Michael Sperber

**Re: Revision of SRFI 70 available***From:*bear

**inexactness vs. exactness***From:*Aubrey Jaffer

**Re: inexactness vs. exactness***From:*bear

**Re: inexactness vs. exactness***From:*Aubrey Jaffer

**Re: inexactness vs. exactness***From:*bear

**Re: inexactness vs. exactness***From:*Aubrey Jaffer

**Re: inexactness vs. exactness***From:*Alan Watson

- Prev by Date:
**Re: Nitpick with FLOOR etc.** - Next by Date:
**Re: inexactness vs. exactness** - Previous by thread:
**Re: inexactness vs. exactness** - Next by thread:
**Re: inexactness vs. exactness** - Index(es):