From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#16365: (* 0 +inf.0) rationale is flawed Date: Tue, 21 Jun 2016 09:57:32 -0400 Message-ID: <87vb12skz7.fsf@netris.org> References: <20140106001719.GI21945@fysh.org> <87r3bqzpbd.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1466519135 23584 80.91.229.3 (21 Jun 2016 14:25:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2016 14:25:35 +0000 (UTC) Cc: Zefram , 16365@debbugs.gnu.org To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue Jun 21 16:25:25 2016 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bFMcD-0007wW-4Y for guile-bugs@m.gmane.org; Tue, 21 Jun 2016 16:25:21 +0200 Original-Received: from localhost ([::1]:52257 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFMcC-0008K5-7m for guile-bugs@m.gmane.org; Tue, 21 Jun 2016 10:25:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFMBp-0003Mo-2s for bug-guile@gnu.org; Tue, 21 Jun 2016 09:58:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFMBm-0002v3-DY for bug-guile@gnu.org; Tue, 21 Jun 2016 09:58:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFMBm-0002uv-9p for bug-guile@gnu.org; Tue, 21 Jun 2016 09:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bFMBm-0004XG-1S for bug-guile@gnu.org; Tue, 21 Jun 2016 09:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 21 Jun 2016 13:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16365 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 16365-submit@debbugs.gnu.org id=B16365.146651747317418 (code B ref 16365); Tue, 21 Jun 2016 13:58:01 +0000 Original-Received: (at 16365) by debbugs.gnu.org; 21 Jun 2016 13:57:53 +0000 Original-Received: from localhost ([127.0.0.1]:49836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFMBd-0004Wr-Du for submit@debbugs.gnu.org; Tue, 21 Jun 2016 09:57:53 -0400 Original-Received: from world.peace.net ([50.252.239.5]:34602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFMBb-0004WI-W4 for 16365@debbugs.gnu.org; Tue, 21 Jun 2016 09:57:52 -0400 Original-Received: from [206.35.36.10] (helo=jojen) by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bFMBV-00030v-4m; Tue, 21 Jun 2016 09:57:45 -0400 In-Reply-To: <87r3bqzpbd.fsf@pobox.com> (Andy Wingo's message of "Tue, 21 Jun 2016 14:41:58 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8098 Archived-At: Andy Wingo writes: > Thoughts, Mark? Sorry for the long delay on this, but briefly, I agree that my rationale was flawed, and that we should make (* 0 ) == 0 in all cases in 2.2. I also suspect that (/ 0 ) should be 0, although that conflicts with R6RS. We should probably investigate the rationale behind R6RS's decision to specify that (/ 0 0.0) returns a NaN before changing that, though. I hope to work more on this soon. Thanks, Mark > On Mon 06 Jan 2014 01:17, Zefram 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