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: Wed, 14 Feb 2018 15:54:28 -0500 Message-ID: <87r2pnnvgb.fsf@netris.org> References: <874lmlrkgc.fsf@netris.org> <87sha5q588.fsf@netris.org> <8d11fe9992e70af48db00d9a35a93a20@ccrma.stanford.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1518641695 22597 195.159.176.226 (14 Feb 2018 20:54:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Feb 2018 20:54:55 +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 Wed Feb 14 21:54:51 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 1em44N-0003cx-Dk for guile-bugs@m.gmane.org; Wed, 14 Feb 2018 21:54:23 +0100 Original-Received: from localhost ([::1]:59197 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1em46N-0007oV-Bt for guile-bugs@m.gmane.org; Wed, 14 Feb 2018 15:56:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1em461-0007Yr-QV for bug-guile@gnu.org; Wed, 14 Feb 2018 15:56:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1em45y-0005Wb-8o for bug-guile@gnu.org; Wed, 14 Feb 2018 15:56:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35390) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1em45y-0005WR-4G for bug-guile@gnu.org; Wed, 14 Feb 2018 15:56:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1em45x-0000xW-Tg for bug-guile@gnu.org; Wed, 14 Feb 2018 15:56:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 14 Feb 2018 20:56:01 +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.15186417103625 (code B ref 30426); Wed, 14 Feb 2018 20:56:01 +0000 Original-Received: (at 30426) by debbugs.gnu.org; 14 Feb 2018 20:55:10 +0000 Original-Received: from localhost ([127.0.0.1]:43287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em457-0000wP-T7 for submit@debbugs.gnu.org; Wed, 14 Feb 2018 15:55:10 -0500 Original-Received: from world.peace.net ([50.252.239.5]:58896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em456-0000wC-PL for 30426@debbugs.gnu.org; Wed, 14 Feb 2018 15:55:09 -0500 Original-Received: from pool-72-93-29-93.bstnma.east.verizon.net ([72.93.29.93] helo=jojen) by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1em450-0007u3-D5; Wed, 14 Feb 2018 15:55:02 -0500 In-Reply-To: <8d11fe9992e70af48db00d9a35a93a20@ccrma.stanford.edu> (bil@ccrma.stanford.edu's message of "Mon, 12 Feb 2018 13:59:24 -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:9006 Archived-At: bil@ccrma.Stanford.EDU writes: > Thanks very much for the informative answer! I am not sure what > (* 0 +nan.0) should return. I lean toward +nan.0 mainly because > I assume NaNs exist to indicate an error somewhere, and you want > that to be returned. It's a sensible position. FWIW, my rationale is that for all exact integers k, (* k x) => (+ x ...) with k copies of x in the arguments. By that rule, (* 0 x) => (+). It's certainly true that NaNs exist to indicate errors, but they might not be propagated to the final result due to control flow, and for a typical formal specification of multiplication-by-exact-integer equivalent to the rule above, the NaN would not be propagated. More generally, if the result would be the same for _any_ exact real substituted in place of the NaN, then I believe it's justifiable to drop the NaN. R7RS-small states a similar rule in section 6.2.4: An arithmetic operation where one operand is NaN returns NaN, unless the implementation can prove that the result would be the same if the NaN were replaced by any rational number. > For (* 0 +inf.0) I have no druthers. > For (/ 0.0 0) and (/ +nan.0 0) s7 throws a divide-by-zero error, > but I have no good reason for doing this. For lack of a more comprehensive framework to decide corner cases involving a mixture of exact and inexact arguments, I've found it useful to use limits to decide the results of numerical operations involving inexact zeroes or infinities. Based on my reading of IEEE 754 and related articles by Kahan, this is the approach that I've found is most justifiable and consistent with IEEE 754. For example, for ( 0.0 y ...), I take the limit of ( x y ...) as x approaches zero from above, and similarly for 'x' in other argument positions. For -0.0, I take the limit as x approaches zero from below. Similarly for the infinities. This rule does not cover cases where more than one argument is an inexact zero or infinity. If one accepts this approach, then (/ 0.0 0) is undefined and (* 0 +inf.0) is 0. > In s7, I'd prefer to say (/ x y ...) is equal to (/ x (* y ...)) in > all cases. FWIW, I believe this is in violation of all RnRS at least as far back as R3RS, which all specify that '/' returns the quotient of its arguments, associating to the left. On the other hand, I've not been shy to deviate from RnRS when I thought it made sense to do so, so I can't complain :) Regards, Mark