Thoughts, Mark? On Mon 06 Jan 2014 01:17, Zefram <zef...@fysh.org> writes:
> 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