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

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.

*To*: srfi-70@xxxxxxxxxxxxxxxxx*Subject*: Re: inexactness vs. exactness*From*: William D Clinger <will@xxxxxxxxxxx>*Date*: Mon, 01 Aug 2005 16:32:41 +0200*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*User-agent*: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5-b21 (berkeley-unix)

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"? If that phrase were interpreted as referring to the error bounds for IEEE binary floating point arithmetic, say, then most implementations of programming languages on Pentium hardware would fail the test. More surprisingly, they would fail the test because they are following a sound recommendation made by William Kahan and others: use the Pentium's extended precision arithmetic whenever possible, even when the ultimate result of the calculation will be represented in double precision. 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. For examples of this problem, use Google to search for "floating point arithmetic"+"double rounding". I think it would be a mistake to specify error bounds so tightly as to rule out substitution of extended precision for double precision. Will

**Follow-Ups**:**flonum precision***From:*Aubrey Jaffer

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