Hi, b...@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