From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#30426: division inconsistency? Date: Thu, 15 Feb 2018 02:35:14 -0500 Message-ID: <87inayogct.fsf@netris.org> References: <874lmlrkgc.fsf@netris.org> <87sha5q588.fsf@netris.org> <8d11fe9992e70af48db00d9a35a93a20@ccrma.stanford.edu> <87r2pnnvgb.fsf@netris.org> <7d3ad28781defb8921e66e6287581af8@ccrma.stanford.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1518680058 26110 195.159.176.226 (15 Feb 2018 07:34:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Feb 2018 07:34:18 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cc: 30426@debbugs.gnu.org To: bil@ccrma.Stanford.EDU Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Feb 15 08:34:14 2018 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emE3V-0006Ht-JA for guile-bugs@m.gmane.org; Thu, 15 Feb 2018 08:34:09 +0100 Original-Received: from localhost ([::1]:46635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emE5X-0008EN-D2 for guile-bugs@m.gmane.org; Thu, 15 Feb 2018 02:36:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emE5P-0008C1-Iy for bug-guile@gnu.org; Thu, 15 Feb 2018 02:36:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emE5K-0006mH-LR for bug-guile@gnu.org; Thu, 15 Feb 2018 02:36:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35687) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1emE5K-0006lx-H5 for bug-guile@gnu.org; Thu, 15 Feb 2018 02:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1emE5K-0007eT-4O for bug-guile@gnu.org; Thu, 15 Feb 2018 02:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 15 Feb 2018 07:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30426 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 30426-submit@debbugs.gnu.org id=B30426.151868015729401 (code B ref 30426); Thu, 15 Feb 2018 07:36:02 +0000 Original-Received: (at 30426) by debbugs.gnu.org; 15 Feb 2018 07:35:57 +0000 Original-Received: from localhost ([127.0.0.1]:43584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emE5F-0007e8-5J for submit@debbugs.gnu.org; Thu, 15 Feb 2018 02:35:57 -0500 Original-Received: from world.peace.net ([50.252.239.5]:59956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emE5D-0007dv-Ad for 30426@debbugs.gnu.org; Thu, 15 Feb 2018 02:35:55 -0500 Original-Received: from pool-72-93-28-176.bstnma.east.verizon.net ([72.93.28.176] helo=jojen) by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1emE56-00048s-UI; Thu, 15 Feb 2018 02:35:49 -0500 In-Reply-To: <7d3ad28781defb8921e66e6287581af8@ccrma.stanford.edu> (bil@ccrma.stanford.edu's message of "Wed, 14 Feb 2018 14:10:52 -0800") 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:9008 Archived-At: Hi Bill, bil@ccrma.Stanford.EDU writes: > But if (* 0 x) is 0, you lose the notion that > (* exact inexact) is inexact. So (* 0 +inf.0) > should be 0.0 or maybe +nan.0. Similarly with > +nan.0, I suppose. No, because (* 0 x) is equivalent to (+), where the x is not an input. In fact, this specific case (multiplication by exact 0) is given as an example where exact 0 may be returned even if the other argument is inexact, by R4RS, R5RS, R6RS, and R7RS. R4RS section 6.5.2, and R5RS section 6.2.2 (Exactness), state: With the exception of 'inexact->exact', the operations described in this section must generally return inexact results when given any inexact arguments. An operation may, however, return an exact result if it can prove that the value of the result is unaffected by the inexactness of its arguments. For example, multiplication of any number by an exact zero may produce an exact zero result, even if the other argument is inexact. R6RS section 11.7.1 (Propagation of exactness and inexactness) states: One general exception to the rule above is that an implementation may return an exact result despite inexact arguments if that exact result would be the correct result for all possible substitutions of exact arguments for the inexact ones. An example is (* 1.0 0) which may return either 0 (exact) or 0.0 (inexact). R7RS section 6.2.2 (Exactness) states: Except for exact, the operations described in this section must generally return inexact results when given any inexact arguments. An operation may, however, return an exact result if it can prove that the value of the result is unaffected by the inexactness of its arguments. For example, multiplication of any number by an exact zero may produce an exact zero result, even if the other argument is inexact. Specifically, the expression (* 0 +inf.0) may return 0, or +nan.0, or report that inexact numbers are not supported, or report that non-rational real numbers are not supported, or fail silently or noisily in other implementation-specific ways. I'm quite sensitive to this issue, so sensitive that I decided to change Guile several years ago so that (* 0 1.0) would return 0.0 instead of 0. My rationale was that if the 1.0 were replaced by +inf.0 or +nan.0, then by IEEE 754 the result should be +nan.0, and therefore that the result was not the same regardless of the value of the inexact argument. I didn't care that R[4567]RS specifically gave this as an example where an exact 0 may be returned, because I judged that it violated the principles of the exactness propagation, and I don't want to return an exact result unless it could in principle be _proved_ to be correct. The new language in R6RS is what changed my mind. In R6RS, you may return an exact result if it "would be the correct result for all possible substitutions of _exact_ arguments for the inexact ones." So, we needn't consider what would happen if +inf.0 or +nan.0 were put in place of the 1.0 in (* 0 1.0), because +inf.0 and +nan.0 are not exact. I think this is the right principle. In mathematics, all real numbers are finite; there are no infinities and no NaNs. I regard the inexact infinities as merely inexact representations of very large finite real numbers. What do you think? Regards, Mark