Re: [PATCH] Handle products with exact 0 differently, etc

[Mark H Weaver <mhw@netris.org>]

Neil Jerram <neil@ossau.uklinux.net> writes:
>> In this case, the inaccuracies associated with inexact arithmetic could
>> result in an infinity being misrepresented as a finite number, or vice
>> versa.  For example, if X is inexact, then we cannot claim that the
>> result of (* 0 (/ X)) is an exact 0, because a small change in X could
>> affect the final answer.
>
> In other words, the argument is that any inexact number might actually
> be infinite.  (Right?)

Yes.

> That strikes me as stretching the idea of inexactness too far; and also
> as not useful, because I'm sure there are many practical ways of
> producing inexact numbers that are provably finite (e.g. sqrt(5)).

There are some cases where it can be proven, but anytime you divide by
an inexact number (or apply any other function with singularities), you
must assume that the finiteness of the result is unknown.  Unless you
keep track of the necessary information about how an inexact number was
computed, you cannot know its finiteness, therefore you must assume the
worst.

One approach to proving finiteness in simple cases might be as follows:
Every inexact number could include an additional flag indicating whether
it's provably finite.  Division by an inexact number would have to
return an inexact number with that flag cleared.  Similarly for other
functions with singularities.  Most other operations would AND the
operand flags together to determine the result flag.

However, I don't currently see that the benefits of this would outweigh
the additional implementation complexity and overhead.

> My guess is that for the majority of programming situations where I
> have an inexact number X, that number is provably finite, and so I'd
> want (* 0 X) to be an exact 0.

Can you give a practical example where it is important for (* 0 X) for
inexact X to produce an exact 0?  If I understood why this was important
(besides the aesthetics of an exact result), I might be more motivated
to try to produce an exact 0 when possible.

> Are you following specific references here?  FWIW, for cases like this,
> the last para of R6RS 11.7.1 allows "either 0 (exact) or 0.0 (inexact)".

Yes, the R6RS does allow (* 1.0 0) to be an exact 0, but that's because
it also allows (* 0 +inf.0) and (* 0 +nan.0) to be an exact 0.  Section
11.7.4.3 provides the following examples:

  (* 0 +inf.0)  ==>  0 or +nan.0
  (* 0 +nan.0)  ==>  0 or +nan.0
  (* 1.0 0)     ==>  0 or 0.0

It follows from the rules of exactness propagation that (* 1.0 0) may be
an exact 0 only if (* 0 X) is an exact 0 for _any_ inexact X.  We
_could_ do this, if we made (* 0 +inf.0) and (* 0 +nan.0) return exact 0
as well.  However, doing this would necessarily destroy the equivalence
of (/ X Y) and (* X (/ Y)), as explained in my first message of this
thread.

The following note in section 11.7.4.3, regarding `min' and `max', gives
a hint of how strictly these exactness rules should be enforced:

  Note: If any argument is inexact, then the result is also inexact
  (unless the procedure can prove that the inaccuracy is not large
  enough to affect the result, which is possible only in unusual
  implementations).  If min or max is used to compare number objects of
  mixed exactness, and the numerical value of the result cannot be
  represented as an inexact number object without loss of accuracy, then
  the procedure may raise an exception with condition type
  &implementation-restriction.

     Best,
      Mark