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.devel Subject: Re: [PATCH] Handle products with exact 0 differently, etc Date: Tue, 01 Feb 2011 23:22:48 -0500 Message-ID: <87aaifuktj.fsf@yeeloong.netris.org> References: <87ipx4vtvg.fsf@yeeloong.netris.org> <87mxmf1gi3.fsf@ossau.uklinux.net> <87k4hjuu82.fsf@yeeloong.netris.org> <87bp2vtduh.fsf@ossau.uklinux.net> <87ei7runpa.fsf@yeeloong.netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1296620595 24896 80.91.229.12 (2 Feb 2011 04:23:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2011 04:23:15 +0000 (UTC) Cc: guile-devel@gnu.org To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 02 05:23:11 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PkUFK-0002pn-L5 for guile-devel@m.gmane.org; Wed, 02 Feb 2011 05:23:11 +0100 Original-Received: from localhost ([127.0.0.1]:34978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkUFJ-0002L5-Oq for guile-devel@m.gmane.org; Tue, 01 Feb 2011 23:23:09 -0500 Original-Received: from [140.186.70.92] (port=56674 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkUF8-0002Jf-23 for guile-devel@gnu.org; Tue, 01 Feb 2011 23:23:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkUF6-0001HX-Rg for guile-devel@gnu.org; Tue, 01 Feb 2011 23:22:57 -0500 Original-Received: from world.peace.net ([216.204.32.208]:55840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkUF6-0001H5-O4 for guile-devel@gnu.org; Tue, 01 Feb 2011 23:22:56 -0500 Original-Received: from ip68-9-118-38.ri.ri.cox.net ([68.9.118.38] helo=freedomincluded) by world.peace.net with esmtpa (Exim 4.69) (envelope-from ) id 1PkUF1-0001f0-39; Tue, 01 Feb 2011 23:22:51 -0500 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1PkUEy-00084j-IS; Tue, 01 Feb 2011 23:22:48 -0500 In-Reply-To: <87ei7runpa.fsf@yeeloong.netris.org> (Mark H. Weaver's message of "Tue, 01 Feb 2011 22:20:33 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 216.204.32.208 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:11503 Archived-At: I wrote: >> Are you following specific references here? FWIW, for cases like this, >> the last para of R6RS 11.7.1 allows "either 0 (exact) or 0.0 (inexact)". > > Yes, the R6RS does allow (* 1.0 0) to be an exact 0, but that's because > it also allows (* 0 +inf.0) and (* 0 +nan.0) to be an exact 0. Section > 11.7.4.3 provides the following examples: > > (* 0 +inf.0) ==> 0 or +nan.0 > (* 0 +nan.0) ==> 0 or +nan.0 > (* 1.0 0) ==> 0 or 0.0 > > It follows from the rules of exactness propagation that (* 1.0 0) may be > an exact 0 only if (* 0 X) is an exact 0 for _any_ inexact X. I apologize, I should have admitted that I am going a bit further than the R6RS strictly requires, based on my understanding of the rationale behind exactness in Scheme. It is true that both the R5RS and the R6RS specifically give (* 0 X), for inexact X, as an example where it is permissible to return an exact 0, without mentioning any associated caveats, e.g. that one must also make (* 0 +inf.0) and (* 0 +nan.0) be an exact 0 as well. I suspect the reason that the R5RS did not mention these caveats is that it does not specify anything about infinities or NaNs. For example, MIT/GNU Scheme evaluates (* 0 X) to exact 0 for inexact X, but that is justified because its arithmetic operations do not produce infinities or NaNs; they throw exceptions instead. As for the R6RS, I confess that a strict reading of the exactness propagation rule does allow (* 0 X) to be 0 for inexact 0, even (* 0 +inf.0) yields something else. That's because their rule requires only that the same result is returned for all possible substitutions of _exact_ arguments for the inexact ones. Since the infinities and NaNs are not exact, they are not considered as possible substitutions. 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. I think that the R6RS is wrong here. As I understand it, the rationale for the exactness system is to allow the construction of provably correct programs, despite the existence of inexact arithmetic. One should be able to trust that any exact number is provably correct, presuming that inexact->exact was not used of course. Is there a compelling reason why (* 0 X) should yield an exact 0 for inexact X? Is there a reason more important than being able to trust that exact values are provably correct? Best, Mark