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

*To*: bear@xxxxxxxxx*Subject*: Re: inexactness vs. exactness*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Sun, 7 Aug 2005 13:21:51 -0400 (EDT)*Cc*: will@xxxxxxxxxxx, srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <Pine.LNX.4.58.0507302308240.6586@xxxxxxxxxxxxxx> (message from bear on Sat, 30 Jul 2005 23:20:08 -0700 (PDT))*References*: <y9ly87s4ud7.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20050731023754.BBC9F1B77B4@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0507302308240.6586@xxxxxxxxxxxxxx>

| Date: Sat, 30 Jul 2005 23:20:08 -0700 (PDT) | From: bear <bear@xxxxxxxxx> | | I know that it's not the right thing in all cases and all times, | but I think it's a good thing in most of the cases I use, for | an operation on exact arguments whose mathematically correct | result is too large to be represented as an exact number, to | (silently) return an inexact number of the highest available | precision. | | Thus, precision escalating out of control in an iterative | algorithm using rationals eventually breaks a point where | the denominator is more than three hundred digits long, | and instead of crashing or bogging down with ever-larger | diophantine fractional calculations, and an addition or | a multiplication or whatever returns a float. There is a third way: report a violation of an implementation restriction when trying to return numbers with more than, say, 16000 bits. Practical calculation on numbers larger than that would need FFT multiplication and other number-theoretic algorithms, which is a lot of hair to support execution of simple programming errors. | This behavior is neither mandated nor forbidden by R5RS. I | think that's a good thing. Your proposal also does not | mandate nor forbid it; I think that's a good thing too. But | it sounds like you came really close to forbidding it, and | may have failed to do so only by accident. So I just wanted | to point it out as a frequently desirable behavior. The sentence: For exact numbers, it is the programmer's responsibility to avoid using numbers with magnitude or precision too large to be represented in the implementation. was adapted from W. Clinger's comments, which I believe were referring to R5RS. The purpose for including it was to clarify the situation, not to make new law. Do I misunderstand? Section 6.2.2 Exactness as I am working on it is appended: -=-=-=-=- | 6.2.2 Exactness | Scheme numbers are either exact or inexact. A number is exact if | it was written as an exact constant or was derived from exact | numbers using only exact operations. A number is inexact if it is infinite, | if it was written as an inexact constant, if it was derived using | inexact ingredients, or if it was derived using inexact operations. | Thus inexactness is a contagious property of a number. Each exact number corresponds to a single mathematical number. For exact numbers, it is the programmer's responsibility to avoid using numbers with magnitude or precision too large to be represented in the implementation. Inexact numbers are approximate. Every mathematical number within the (convex) range of inexacts supported by an implementation will round to an inexact number on input or as a result of computation. The neighborhood of mathematical numbers rounding to a particular inexact number must be simply connected. Because real infinities are mandated (in implementations supporting inexacts), all mathematical real numbers map to inexact numbers. For non-real complex numbers, it is the programmer's responsibility to avoid using numbers with magnitude too large to be represented in the implementation. | If two implementations produce exact results for a computation that | did not involve inexact intermediate results, the two ultimate | results will be mathematically equivalent. This is not true of | computations involving inexact numbers because approximate methods | such as floating point arithmetic may be used, but it is the duty | of each implementation to make the result as close as practical to | the mathematically ideal result. | Rational operations such as `+' should always produce exact results | when given exact arguments. If the operation is unable to produce | an exact result, then it may either report the violation of an | implementation restriction or it may silently coerce its result to | an inexact value. See section 6.2.3 Implementation restrictions. | With the exception of inexact->exact, `round->exact', `ceiling->exact', `floor->exact', and `truncate->exact', | the operations described in this section must return | inexact results when given any inexact arguments.

**Follow-Ups**:**Re: inexactness vs. exactness***From:*Paul Schlie

**Re: inexactness vs. exactness***From:*Bradley Lucier

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

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

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

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