[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16365: (* 0 +inf.0) rationale is flawed
From: |
Andy Wingo |
Subject: |
bug#16365: (* 0 +inf.0) rationale is flawed |
Date: |
Tue, 21 Jun 2016 14:41:58 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Thoughts, Mark?
On Mon 06 Jan 2014 01:17, Zefram <address@hidden> 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
- bug#16365: (* 0 +inf.0) rationale is flawed,
Andy Wingo <=