[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*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: Wrapping up SRFI-70*From*: bear <bear@xxxxxxxxx>*Date*: Tue, 16 Aug 2005 20:06:43 -0700 (PDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050815034459.8A6981B77B4@xxxxxxxxxxxxxxxx>*References*: <20050810030837.1C5711B77B4@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0508092135590.25357@xxxxxxxxxxxxxx> <20050815034459.8A6981B77B4@xxxxxxxxxxxxxxxx>

On Sun, 14 Aug 2005, Aubrey Jaffer wrote: > | 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. Yes. It keeps track of the sign, even in cases where the sign is ambiguous or undefined. I think this is a problem. When something is divided by zero, pretending that the result has any particular sign at all is misleading. This is the most common operation that results in an infinity, but it is an infinity, and not an overflow; it is the result of a mathematically poorly defined operation. For example (/ 32 (- 7.1 (+ 4.2 2.9))) if performed using floating point arithmetic, is an overflow, but has positive or negative sign depending solely on rounding error. If performed using exact arithmetic, or arithmetic in BCD where no rounding is required, it is a division by a true zero and the result is properly an unsigned infinity or NaN. IEEE 754 may recommend a sign, but if it does, then it is based on the representation, and not on any underlying mathematical reality. An actual overflow, such as (* 2 MAXFLONUM), has an unambiguous sign, but is not actually an infinity; it is merely a number too large to represent in our current encoding scheme. Since this isn't actually an infinity, it is quite right to state that multiplying such an object by an exact zero may result in an exact zero. In fact, it *DOES* result, mathematically speaking, in zero; allowing implementations to return inexact results in this case is just a bow to implementation convenience and the desire for implementations that give high speed on hardware that presents an imperfect model of mathematics. Cases where you get an actual infinity that also has an unambiguous sign are, IME, much rarer according to the laws of actual mathematics than they are in software and hardware approximations of mathematics. This is a flaw in software, to be tolerated perhaps in the name of convenience and speed on real-life hardware and in the name of reducing the number of cases that need to be handled, but not to be mandated or required when someone may want to do the actual Right Thing instead. > | The requirements you make of rounding for inexact numbers are > | reasonable-sounding, but cannot be carried forward through any > | level of abstraction. >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. I empathize with your frustration, but: did you really mean to use the word "complex" here, meaning numbers with real and imaginary parts? If so I don't think I see the logic or point of this sentence. > | 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. You are correct that if the object being multiplied by an exact zero may be an actual infinity then the result is undefined. Not only are we unable to give its exactness, we are unable to give its value. It is an unknown number. However, multiplication by exact zero certainly does "trump" mere overflows (signed numbers that are too large for the current encoding to represent). Under your current formulation, are infinities distinguished from overflows? Do you think it would be a reasonable thing to do? Do you think it would be a reasonable thing to forbid anyone to do? > | 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? If the other operand is anything other than an actual infinity, then zero (EXACTLY zero) is the correct mathematical result. The latitude to return inexact zero is a concession to simple, efficient code that runs fast on hardware which presents a flawed model of mathematics; it permits the flaw to affect the results. *Requiring* the flaw to affect the results is, I believe, The Wrong Thing. Bear

**Follow-Ups**:**Re: Wrapping up SRFI-70***From:*Paul Schlie

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

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

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

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

- Prev by Date:
**floor->exact etc** - Next by Date:
**Revision of SRFI 70 available** - Previous by thread:
**Re: Wrapping up SRFI-70** - Next by thread:
**Re: Wrapping up SRFI-70** - Index(es):