On Mon, 18 Jul 2005, Aubrey Jaffer wrote:

> | Date: Mon, 18 Jul 2005 08:50:50 -0700 (PDT)
> | From: bear <xxxxxx@sonic.net>
> |
> | This draft effectively eliminates certain properties of
> | inexactness vs. exactness,
>
>SRFI-70 sharpens the distinction between inexacts and exacts.

It requires inexact numbers in many situations where exact
numbers can be produced.

>From
>the R5RS notation of inexacts it deduces their nature as real
>neighborhoods.

A point on which we disagree.  I don't think any such nature
was inherent in R5RS.

> Because exact numbers in Scheme designate single
> mathematical numbers, the idea of exactness as a superficial attribute
> of numbers must be jettisoned.

A conclusion based on the point on which we disagree.  It is
not at all surprising that we disagree about this conclusion
also.  Inexactness denotes that we cannot be certain that the
specific, precise number is the correct specific precise number;
it does not transform the number into a numeric neighborhood.
Exact and inexact numbers, except for this sole quality, denote
exactly the same thing.

>  Inexactness is as much a property of calculation as it is of data
>  sources.  A language having latent types does not obviate the
>  programmer's expectation that a calculation involving transcendental
>  functions should return an inexact result.

But if error-free results happen to be available, we should
therefore disregard them?  What?!

>      An operation may, however, return an exact result if it can
>      prove that the value of the result is unaffected by the
>      inexactness of its arguments.  For example, multiplication of
>      any number by an exact zero may produce an exact zero result,
>      even if the other argument is inexact.
>
>  By those sentences, inexactness is a contagious property of all
>  numbers; except 0, the only number whose exactness is contagious!
>  This conflicts with the statement earlier in 6.2.2:

No... by those sentences, inexactness in the sense of possible
error propagates forward from arguments into results wherever
we cannot prove that the inexactness doesn't introduce the
possibility of error in results.  A multiplication by an exact
zero is only one of many possibilities here.

> | and in doing so it creates a type distinction where none was
> | before.
>
> Is exactness this "type distinction"?

Yep.  What you're doing is declaring that in some circumstances
we have to pretend we are uncertain of our results even though
there is a mathematical certainty that they are correct.  The
sole purpose for this is to fulfill an expectation that inexact
results will be returned; you are valuing numeric type above
reporting correct answers.

> | In the dialect spec'd by R5RS, there was never any situation
> | where an inexact number was required and an exact one would
> | not do; thus it was entirely correct for implementations to
> | return exact numbers whenever the opportunity presented
> | itself.
>
>Implementations like Elk, Gambit, and Mzscheme signal errors for
>division by exact zero, but return infinities for division by inexact
>zero.  This is a "situation where an inexact number was required and
>an exact one would not do".

That wasn't behavior specified by R5RS, was it?  That was the
decision of a few implementors, who created an inconsistency
and a type distinction.  This inconsistency was not created
by the standard, and does not need to be "fixed" in the standard.

> This created the contradiction noted above.  With exact 0 being
> stronger than inexact 0.0, it also leads to the opaque practice of
> controlling the behavior of EXPT and `/' at 0 by coercing the
> exactness of its arguments.

"strength" has nothing to do with it.  It is merely a mathematical
fact.  Any number may be multiplied by zero to get zero.  If there
is no uncertainty that the zero is the correct value (ie, if it's
an "exact" zero in R5RS parlance) it does not matter a bit whether
there is certainty about the other operand.  Differences in the
value of the other operand do not introduce any mathematical
uncertainty (inexactness) that the result of zero is correct.
Infinity in the sense of "some number too large to represent"
is no exception to this rule;  Infinity in the sense of a true
mathematical infinity is, but the result of such a
multiplication is neither exact nor inexact; it is a NaN.

> I have authority to propose whatever I want.  And the R6RS editors
> have the authority to accept it, modify it, or ignore it.

Yes, I suppose that's what it comes down to.  I hope to see
better treatment of numeric error objects than you propose.

> I do a lot of numerical computing (near-field optics lately).
> Division by zero happens.  If SIN of some complicated expression
> returns an exact zero .001% of the time, then .001% of the time I will
> get an exception from the division taking that expression as a divisor
> rather than an infinity which lets the program continue.

This problem belongs to your implementation, not to R5RS.
It would be perfectly compliant with R5RS and consistent
treatment of numbers if your system raised an exception
in both cases or returned an error object (such as an
infinity or a NaN) in both cases.

>That is broken behavior; but that is what R5RS-compliant Mzscheme 205
>does; and probably other implementations also.

I don't argue with you that it is broken behavior; but I
don't see the point in predicating changes to the standard
based on a few implementations' inconsistent treatment of
exact and inexact numbers.

The situation is that you have a headache because you
don't know whether the results will be exact or inexact,
*and* the implementations you're using happen to treat
exact and inexact numbers inconsistently;

Inconsistency && Uncertainty -> Headache.

You want this headache to go away, so do the ordinary
boolean math, and you get...

!Headache -> !Inconsistency || !Uncertainty

In other words, this headache goes away if you know whether
the results will be exact or inexact, *or* it goes away if
implementations treat exact and inexact numbers consistently.
Since the former involves pretending there is a possibility
of error even where there is none and we can prove it, and
thus discards useful information, why not ask for the latter
instead?

Isn't the inconsistent treatment (one continues and one
signals an error) your problem?  Why not call that incorrect
behavior instead of calling an occasional blessing of extra
information about the accuracy of the answer incorrect
behavior?

				Bear