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

*To*: will@xxxxxxxxxxx*Subject*: flonum precision*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Mon, 1 Aug 2005 22:55:56 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <y9lll3l683a.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (message from William D Clinger on Mon, 01 Aug 2005 16:32:41 +0200)*References*: <y9lll3l683a.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

| From: William D Clinger <will@xxxxxxxxxxx> | Date: Sun, 31 Jul 2005 20:35:41 -0400 | | Aubrey Jaffer wrote: | > My current thinking is to modify SRFI-70 to incorporate this | > distinction between exact and inexact: | | The last paragraph of his proposed wording ran as follows: | | > It is the duty of each implementation to make the result of | > mathematical expressions as close as practical to the | > mathematically ideal result. The error in results of optimized | > or compiled mathematical expressions must be no larger than the | > error band expected from the combination of the error bands of | > its component operations. | | That last sentence goes to the brink of a precipice, if not | beyond. What is meant by "expected from the combination of | the error bands of its component operations"? The idea was that if each operation were executed by a separate procedure call, then the precision of results executed in aggregated code would not be worse. | ... | Most of the time, extended precision improves the accuracy | of a sequence of arithmetic operations. Every once in a | while, however, the use of extended precision *reduces* | the accuracy compared to the use of double precision for | the same sequence of operations. Furthermore the reduced | accuracy can make the error of the calculation in extended | precision larger in magnitude than the error that is allowed | for the corresponding double precision calculation. Okay. I will remove the second sentence. -=-=-=- With the range of number representations we have been discussing, some of "6.2.3 Implementation restrictions" is seeming poorly specified: If, however, an exact number is operated upon so as to produce an inexact result (as by `sqrt'), and if the result is represented as a flonum, then the most precise flonum format available must be used; but if the result is represented in some other way then the representation must have at least as much precision as the most precise flonum format available. The second half is a strong statement; why are flonums specifically called out in the first half? And specifically which representations are "flonums"? The only definition R5RS gives for flonums is "Machine representations such as fixed point and floating point are referred to by names such as fixnum and flonum." Would floating-point numbers with latent explicit precision be flonums? Such a representation may well support arbitrary precision; in which case the term "most precise flonum format available" is not well-defined for the implementation.

**Follow-Ups**:**Re: flonum precision***From:*bear

**References**:**Re: inexactness vs. exactness***From:*William D Clinger

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