[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*: bear@xxxxxxxxx*Subject*: Re: Wrapping up SRFI-70*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Sun, 14 Aug 2005 23:44:59 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <Pine.LNX.4.58.0508092135590.25357@xxxxxxxxxxxxxx> (message from bear on Tue, 9 Aug 2005 22:37:41 -0700 (PDT))*References*: <20050810030837.1C5711B77B4@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0508092135590.25357@xxxxxxxxxxxxxx>

| Date: Tue, 9 Aug 2005 22:37:41 -0700 (PDT) | From: bear <bear@xxxxxxxxx> | | Having a numeric-error object (such as nan) Your suggestion is a better treatment of not-a-number. 0/0 has been recast as the numeric error-object. | that propagates | forward in calculations from a division by zero or other | erroneous operation answers the requirements in the abstract far | better than introducing and attempting to reason about | "infinities." I am hardly the one introducing infinities! At least nine implementations of Scheme employ IEEE-754 infinities. | It allows people to avoid deeply nested checks for | zero, instead testing whenever they like whether the most recent | iteration of their algorithm has produced the error object. You | can test for it and explicitly throw an exception if that's how | you want to handle it, or you can make a substitution or | correction explicitly and carry on. Infinities do all that, and keep track of the sign of overflows as well. | Given the usual vast differences in both absolute range and | precision between exact and inexact notations, reasoning about | "infinity" in exact and inexact forms is difficult and frequently | produces transparently wrong answers when numbers of both exact | and inexact forms are used. Given that, I'd have to regard | numerics with nans as a superior choice mathematically and | technically to numerics with infinities, for a language that | distinguishes exact and inexact numbers. I have years of experience using bignums and IEEE-754 flonums in Scheme. There is practically no overlap between those domains (just the Landau-Mignotte Bound of coefficients when factoring polynomials). Predicating infinities, which are useful for flonum calculations, on some hypothesized interaction which has not been manifest in practice is unconvincing. | There is also (pardon me for saying this, but...) faint and fuzzy | thinking in this SRFI about the properties of exactness and | inexactness. Exact numbers, by definition, already denote a | single mathematical number, with infinite precision. Since that was not clear to everyone, SRFI-70 explicitly states it in order to prevent "faint and fuzzy thinking". | The requirements you make of rouding for inexact numbers are | reasonable-sounding, but cannot be carried forward through any | level of abstraction. With an abstraction such as a procedure, | we define a new mathematical operation in terms of one or more | existing operations. Even if those existing (primitive) | operations conform to your rounding requirement (simple | connectivity), there is no way to assure that the composite | operation represented by an abstraction also does so. I have replaced that language with the weakest formulation yet: In this SRFI, the definition of inexact numbers is strengthened by their not being subject to the caution about "precision too large to be represented in the implementation". Only magnitudes too large are cautioned: For inexact numbers, it is the programmer's responsibility to avoid using complex numbers with magnitude too large to be represented in the implementation. | The SRFI also proposes to repeal an implementation's power to | return an exact number when it can prove that the result is | exactly known. The specific example given in R5RS uses an exact | zero as an example. This example is capital-T True, according to | laws much deeper than the surface consistency on which grounds | you object to it, because zero is a multiplicative identity | element. Exactness and inexactness are not defined mathematically by R5RS. You have objected to my attempts to define inexactness in terms of topology. You can't have it both ways. With as weak a formulation of inexactness as is given above, claims that exact 0 trumps infinities can't appeal to mathematics. | Forbidding an implementation to return an exact zero in | that situation is to ignore a fundamental law of mathematics and | also forbid the implementation from providing true and | potentially useful information to its user. R5RS also allows an implementation to return inexact zero. Is that wrong? Do you feel that latitude should be removed?

**Follow-Ups**:**Re: Wrapping up SRFI-70***From:*bear

**References**:**Wrapping up SRFI-70***From:*Aubrey Jaffer

**Re: Wrapping up SRFI-70***From:*bear

- Prev by Date:
**Re: Wrapping up SRFI-70** - Next by Date:
**Re: Wrapping up SRFI-70** - Previous by thread:
**Re: Wrapping up SRFI-70** - Next by thread:
**Re: Wrapping up SRFI-70** - Index(es):