| Date: Tue, 9 Aug 2005 22:37:41 -0700 (PDT)
 | From: bear <xxxxxx@sonic.net>
 |
 | 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?