On Tue, 9 Aug 2005, Aubrey Jaffer wrote:

>Its time to wrap up SRFI-70.
>
>As with my other SRFIs, the Issues section generates no discussion,
>even though it has the issues I consider unsettled.

Yes, I consider them unsettled too - and largely unsettlable
in the way this SRFI is attempting to do them.  With some
regrets, I think I also recommend withdrawal.

Having a numeric-error object (such as nan) 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."  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.

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.

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.

Some numbers cannot be represented exactly on any finite machine
architecture because their representations would be too large to
fit.  "Precision" in the sense of representation length in exact
numbers decides the size of the set of numbers we can represent,
not the degree to which those numbers are precisely represented.

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.

For example, if I round two numbers up as I read them, and
then add them and round the result of addition up, I have
already reached a point where the "exact" result would be
rounded to an inexact number which is not the number
returned from the addition.  Addition in this case is a
composite operation because it subsumes the rounding errors
of its arguments.  The fact that it adds a rounding error
of its own makes matters even more confused.

So introducing the rounding requirements you do, without
specifying exactly which primitive operations they apply to,
does not permit any "ordinary" implementation of composite
mathematical operations, because it is impossible to define a
composite operation without making it subject to the same
requirement, and also impossible to assure that it meets
that requirement.

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.  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.

> Given the vagueness of the term "flonum", the section 6.2.3
> paragraphs giving requirements for systems with flonums are not
> dangerous in terms of preventing interesting implementations;
> and SRFI-70 doesn't change them.  It would be nice to improve
> it; but converting exact to inexact is a thorny problem.

Agreed fully, but....

I think this SRFI is like an attempt to hold jelly in place with
nails; there's a good thought, and nails are a valid way to hold
some things in place, but for this particular problem a different
approach is likely to be better.

				Bear