Hi Bill,
b...@ccrma.stanford.edu writes:
> But if (* 0 x) is 0, you lose the notion that
> (* exact inexact) is inexact. So (* 0 +inf.0)
> should be 0.0 or maybe +nan.0. Similarly with
> +nan.0, I suppose.
No, because (* 0 x) is equivalent to (+), where the x is not an input.
In fact, this spe
But if (* 0 x) is 0, you lose the notion that
(* exact inexact) is inexact. So (* 0 +inf.0)
should be 0.0 or maybe +nan.0. Similarly with
+nan.0, I suppose.
b...@ccrma.stanford.edu writes:
> Thanks very much for the informative answer! I am not sure what
> (* 0 +nan.0) should return. I lean toward +nan.0 mainly because
> I assume NaNs exist to indicate an error somewhere, and you want
> that to be returned.
It's a sensible position. FWIW, my ratio
Thanks very much for the informative answer! I am not sure what
(* 0 +nan.0) should return. I lean toward +nan.0 mainly because
I assume NaNs exist to indicate an error somewhere, and you want
that to be returned. For (* 0 +inf.0) I have no druthers.
For (/ 0.0 0) and (/ +nan.0 0) s7 throws a di
Mark H Weaver writes:
> 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
Sorry, I meant to write (/ 1.0 0) => +inf.0, which is one o
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
A possible inconsistency:
scheme@(guile-user)> (version)
$1 = "2.0.13"
scheme@(guile-user)> (/ 1 (* 0 +nan.0))
$2 = +nan.0
scheme@(guile-user)> (/ 1 0 +nan.0)
:3:0: In procedure #input>:3:0 ()>:
:3:0: Throw to key `numerical-overflow' with args `("/"
"Numerical overflow" #f #f)
scheme@(guile-u
