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 22:20:33 -0500 Message-ID: <87ei7runpa.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1296617063 12211 80.91.229.12 (2 Feb 2011 03:24:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2011 03:24:23 +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 04:24:18 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 1PkTKK-0003C6-KO for guile-devel@m.gmane.org; Wed, 02 Feb 2011 04:24:16 +0100 Original-Received: from localhost ([127.0.0.1]:37302 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkTHB-0000kK-97 for guile-devel@m.gmane.org; Tue, 01 Feb 2011 22:21:01 -0500 Original-Received: from [140.186.70.92] (port=50696 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkTH1-0000jI-Oa for guile-devel@gnu.org; Tue, 01 Feb 2011 22:20:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkTGz-0008MF-KJ for guile-devel@gnu.org; Tue, 01 Feb 2011 22:20:50 -0500 Original-Received: from world.peace.net ([216.204.32.208]:54339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkTGz-0008MB-Db for guile-devel@gnu.org; Tue, 01 Feb 2011 22:20:49 -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 1PkTGs-0001SY-Pu; Tue, 01 Feb 2011 22:20:43 -0500 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1PkTGj-00081a-9b; Tue, 01 Feb 2011 22:20:33 -0500 In-Reply-To: <87bp2vtduh.fsf@ossau.uklinux.net> (Neil Jerram's message of "Wed, 02 Feb 2011 01:38:46 +0000") 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:11502 Archived-At: Neil Jerram writes: >> In this case, the inaccuracies associated with inexact arithmetic could >> result in an infinity being misrepresented as a finite number, or vice >> versa. For example, if X is inexact, then we cannot claim that the >> result of (* 0 (/ X)) is an exact 0, because a small change in X could >> affect the final answer. > > In other words, the argument is that any inexact number might actually > be infinite. (Right?) Yes. > That strikes me as stretching the idea of inexactness too far; and also > as not useful, because I'm sure there are many practical ways of > producing inexact numbers that are provably finite (e.g. sqrt(5)). There are some cases where it can be proven, but anytime you divide by an inexact number (or apply any other function with singularities), you must assume that the finiteness of the result is unknown. Unless you keep track of the necessary information about how an inexact number was computed, you cannot know its finiteness, therefore you must assume the worst. One approach to proving finiteness in simple cases might be as follows: Every inexact number could include an additional flag indicating whether it's provably finite. Division by an inexact number would have to return an inexact number with that flag cleared. Similarly for other functions with singularities. Most other operations would AND the operand flags together to determine the result flag. However, I don't currently see that the benefits of this would outweigh the additional implementation complexity and overhead. > My guess is that for the majority of programming situations where I > have an inexact number X, that number is provably finite, and so I'd > want (* 0 X) to be an exact 0. Can you give a practical example where it is important for (* 0 X) for inexact X to produce an exact 0? If I understood why this was important (besides the aesthetics of an exact result), I might be more motivated to try to produce an exact 0 when possible. > 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. We _could_ do this, if we made (* 0 +inf.0) and (* 0 +nan.0) return exact 0 as well. However, doing this would necessarily destroy the equivalence of (/ X Y) and (* X (/ Y)), as explained in my first message of this thread. The following note in section 11.7.4.3, regarding `min' and `max', gives a hint of how strictly these exactness rules should be enforced: Note: If any argument is inexact, then the result is also inexact (unless the procedure can prove that the inaccuracy is not large enough to affect the result, which is possible only in unusual implementations). If min or max is used to compare number objects of mixed exactness, and the numerical value of the result cannot be represented as an inexact number object without loss of accuracy, then the procedure may raise an exception with condition type &implementation-restriction. Best, Mark