From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Zefram Newsgroups: gmane.lisp.guile.bugs Subject: bug#16464: + folding differs between compiler and interpreter Date: Thu, 16 Jan 2014 12:46:29 +0000 Message-ID: <20140116124629.GC21945@fysh.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1389876424 15639 80.91.229.3 (16 Jan 2014 12:47:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 12:47:04 +0000 (UTC) To: 16464@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Jan 16 13:47:10 2014 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 1W3mLl-0006r0-Qs for guile-bugs@m.gmane.org; Thu, 16 Jan 2014 13:47:10 +0100 Original-Received: from localhost ([::1]:60435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3mLl-0005Uj-DG for guile-bugs@m.gmane.org; Thu, 16 Jan 2014 07:47:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3mLf-0005Ua-Ta for bug-guile@gnu.org; Thu, 16 Jan 2014 07:47:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3mLe-0001Ka-NM for bug-guile@gnu.org; Thu, 16 Jan 2014 07:47:03 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3mLe-0001KW-JP for bug-guile@gnu.org; Thu, 16 Jan 2014 07:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W3mLe-0005hD-8L for bug-guile@gnu.org; Thu, 16 Jan 2014 07:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 16 Jan 2014 12:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 16464 X-GNU-PR-Package: guile X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-guile@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.138987641521880 (code B ref -1); Thu, 16 Jan 2014 12:47:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 16 Jan 2014 12:46:55 +0000 Original-Received: from localhost ([127.0.0.1]:52965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3mLW-0005gp-2M for submit@debbugs.gnu.org; Thu, 16 Jan 2014 07:46:54 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33710) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3mLS-0005gg-JY for submit@debbugs.gnu.org; Thu, 16 Jan 2014 07:46:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3mLQ-0001Jh-Iw for submit@debbugs.gnu.org; Thu, 16 Jan 2014 07:46:49 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:51151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3mLQ-0001Jd-G5 for submit@debbugs.gnu.org; Thu, 16 Jan 2014 07:46:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3mLP-0005TV-9V for bug-guile@gnu.org; Thu, 16 Jan 2014 07:46:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3mLJ-0001Iu-BD for bug-guile@gnu.org; Thu, 16 Jan 2014 07:46:47 -0500 Original-Received: from river.fysh.org ([2001:41d0:8:d47f::2]:38169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3mLJ-0001IW-4m for bug-guile@gnu.org; Thu, 16 Jan 2014 07:46:41 -0500 Original-Received: from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1W3mL7-0003x3-IG; Thu, 16 Jan 2014 12:46:29 +0000 Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7392 Archived-At: The + procedure left-folds its arguments in interpreted code and right-folds its arguments in compiled code. This may or may not be a bug. Obviously, with exact numbers the direction of folding makes no difference. But the difference is easily seen with flonums, as flonum addition is necessarily non-associative. For example, where flonums are IEEE doubles: scheme@(guile-user)> ,o interp #f scheme@(guile-user)> (+ 1.0 (expt 2.0 -53) (expt 2.0 -53)) $1 = 1.0000000000000002 scheme@(guile-user)> (+ (expt 2.0 -53) (expt 2.0 -53) 1.0) $2 = 1.0 scheme@(guile-user)> ,o interp #t scheme@(guile-user)> (+ 1.0 (expt 2.0 -53) (expt 2.0 -53)) $3 = 1.0 scheme@(guile-user)> (+ (expt 2.0 -53) (expt 2.0 -53) 1.0) $4 = 1.0000000000000002 Compiler and interpreter agree when the order of operations is explicitly specified: scheme@(guile-user)> (+ (+ 1.0 (expt 2.0 -53)) (expt 2.0 -53)) $5 = 1.0 scheme@(guile-user)> (+ 1.0 (+ (expt 2.0 -53) (expt 2.0 -53))) $6 = 1.0000000000000002 If your flonums are not IEEE double then the exponent in the test case has to be adapted. R5RS and the Guile documentation are both silent about the order of operations in cases like this. I do not regard either left-folding or right-folding per se as a bug. A portable Scheme program obviously can't rely on a particular behaviour. My concern here is that the compiler and interpreter don't match, making program behaviour inconsistent on what is notionally a single implementation. That mismatch may be a bug. I'm not aware of any statement either way on whether you regard such mismatches as bugs. (An explicit statement in the documentation would be most welcome.) R6RS does have some guidance about the proper behaviour here. The description of the generic arithmetic operators doesn't go into such detail, just describing it as generic. It can be read as implying that the behaviour on flonums should match the behaviour of the flonum-specific fl+. The description of fl+ (libraries section 11.3 "Flonums") says it "should return the flonum that best approximates the mathematical sum". That suggests that it shouldn't use a fixed sequence of dyadic additions operations, and in my test case should return 1.0000000000000002 regardless of the order of operands. Obviously that's more difficult to achieve than just folding the argument list with dyadic addition. Interestingly, fl+'s actual behaviour differs both from + and from the R6RS ideal. It left-folds in both compiled and interpreted code: scheme@(guile-user)> (import (rnrs arithmetic flonums (6))) scheme@(guile-user)> ,o interp #f scheme@(guile-user)> (fl+ 1.0 (expt 2.0 -53) (expt 2.0 -53)) $7 = 1.0 scheme@(guile-user)> (fl+ (expt 2.0 -53) (expt 2.0 -53) 1.0) $8 = 1.0000000000000002 scheme@(guile-user)> ,o interp #t scheme@(guile-user)> (fl+ 1.0 (expt 2.0 -53) (expt 2.0 -53)) $9 = 1.0 scheme@(guile-user)> (fl+ (expt 2.0 -53) (expt 2.0 -53) 1.0) $10 = 1.0000000000000002 fl+'s behaviour is not a bug. The R6RS ideal is clearly not mandatory, and the Guile documentation makes no stronger claim than that its fl+ conforms to R6RS. As it is consistent between compiler and interpreter, it is not subject to the concern that I'm raising in this ticket about the generic +. -zefram