Commit 5e7918077a4015768a352ab19e4a8e94531bc8aa says
A note on the rationale for (* 0 +inf.0) being a NaN and not exact 0:
The R6RS requires that (/ 0 0.0) return a NaN value, and that (/ 0.0)
return +inf.0. We would like (/ x y) to be the same as (* x (/ y)),
This identity doesn't actually hold. For example, on guile 2.0.9 with
IEEE double flonums:
scheme@(guile-user)> (/ (expt 2.0 -20) (expt 2.0 -1026))
$36 = 6.857655085992111e302
scheme@(guile-user)> (* (expt 2.0 -20) (/ (expt 2.0 -1026)))
$37 = +inf.0
This case arises because the dynamic range of this flonum format is
slightly asymmetric: 2^-1026 is representable, but 2^1026 overflows.
So the rationale for (* 0 +inf.0) yielding +nan.0 is flawed. As the
supposed invariant and the rationale are not in the actual documentation
(only mentioned in the commit log) this is not necessarily a bug.
But worth thinking again to determine whether the case for adopting
the flonum behaviour here is still stronger than the obvious case for
the exact zero to predominate. (Mathematically, multiplying zero by an
infinite number does yield zero. Let alone multiplying it by a merely
large finite number, which is what the flonum indefinite `infinity'
really represents.)
-zefram
