GNU bug report logs - #16365
(* 0 +inf.0) rationale is flawed

Previous Next

Package: guile;

Reported by: Zefram <zefram <at> fysh.org>

Date: Mon, 6 Jan 2014 00:18:01 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Zefram <zefram <at> fysh.org>
To: 16365 <at> debbugs.gnu.org
Subject: bug#16365: (* 0 +inf.0) rationale is flawed
Date: Mon, 6 Jan 2014 00:17:19 +0000
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




This bug report was last modified 8 years and 359 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.