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