bug#30426: division inconsistency?

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

Hi,

bil@ccrma.Stanford.EDU writes:

> scheme@(guile-user)> (help '/)
> - Scheme Procedure: / [x [y .  rest]]
>      Divide the first argument by the product of the remaining
>      arguments.  If called with one argument Z1, 1/Z1 is returned.

This help text is indeed incorrect.  In fact, (/ x y z) is evaluated as
(/ (/ x y) z), which is not necessarily the same as (/ x (* y z)) when
using inexact arithmetic.

> A possible inconsistency:
>
> scheme@(guile-user)> (version)
> $1 = "2.0.13"
>
> scheme@(guile-user)> (/ 1 (* 0 +nan.0))
> $2 = +nan.0

Many years ago, I concluded that (* 0 +nan.0) and (* 0 +inf.0) should be
+nan.0, and that's what Guile does.  I now believe that (* 0 <anything>)
should be 0.  Both of these behaviors are allowed by the R6RS.  Note
that when I write '0', I mean an _exact_ zero.  So, the above expression
may raise an exception in a future version of Guile.

> scheme@(guile-user)> (/ 1 0 +nan.0)
> <unnamed port>:3:0: In procedure #<procedure 5557c36be9c0 at <current
> input>:3:0 ()>:
> <unnamed port>:3:0: Throw to key `numerical-overflow' with args `("/"
> "Numerical overflow" #f #f)

The R6RS specifies that if all arguments to '/' are exact, then the
divisors must all be nonzero.  That does not apply to the above '/' call
because of the inexact +nan.0 argument.  However, our compiler
transforms (/ x y z) to (/ (/ x y) z) in an early pass.

> scheme@(guile-user)> (/ 1 +nan.0 0)
> <unnamed port>:5:0: In procedure #<procedure 55ff47f4ad00 at <current
> input>:5:0 ()>:
> <unnamed port>:5:0: Throw to key `numerical-overflow' with args `("/"
> "Numerical overflow" #f #f)

This should probably return +nan.0, and that's what happens in Guile 2.2
for compiled code.  For some of these edge cases, our compiler has
different behavior than our core numeric procedures.

Our core '/' operator, as defined in numbers.c, raises an exception for
(/ x 0), for any 'x'.  This does not conform to the R6RS, which
specifies that (/ 0.0 0) => +inf.0.  I don't think that rule makes sense
because the sign of the result cannot be justified.  (/ 1 0.0) => +inf.0
and (/ 1 -0.0) => -inf.0 are more justifiable because of the signed
inexact zeroes, but an exact zero is not signed.

However, it may be that we should change this to conform to the R6RS,
and certainly it would be good for our compiler and interpreter to agree
on all of these edge cases.

> scheme@(guile-user)> (* +nan.0 0)
> $1 = +nan.0
> scheme@(guile-user)> (/ 1 +nan.0)
> $2 = +nan.0
>
> similarly with +inf.0:
>
> scheme@(guile-user)> (/ 1 (* +inf.0 0))
> $3 = +nan.0

If we change Guile so that (* 0 x) => 0 for all x, then the expression
above will raise an exception in a future version of Guile.

> scheme@(guile-user)> (/ 1 +inf.0 0)
> <unnamed port>:6:0: In procedure #<procedure 5557c36f7740 at <current
> input>:6:0 ()>:
> <unnamed port>:6:0: Throw to key `numerical-overflow' with args `("/"
> "Numerical overflow" #f #f)

As with the (/ 1 +nan.0 0) case above, this should probably return
+nan.0, and that's what happens in Guile 2.2 for compiled code.

What do you think?

    Regards,
      Mark