From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Handle products with exact 0 differently, etc Date: Tue, 1 Feb 2011 23:28:50 -0500 Message-ID: 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> <87aaifuktj.fsf@yeeloong.netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1296620961 26116 80.91.229.12 (2 Feb 2011 04:29:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2011 04:29:21 +0000 (UTC) Cc: guile-devel@gnu.org, Neil Jerram To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 02 05:29:17 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 1PkUL3-0004a6-6e for guile-devel@m.gmane.org; Wed, 02 Feb 2011 05:29:12 +0100 Original-Received: from localhost ([127.0.0.1]:33091 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkUKv-0003V8-Vz for guile-devel@m.gmane.org; Tue, 01 Feb 2011 23:28:58 -0500 Original-Received: from [140.186.70.92] (port=46286 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkUKq-0003V1-C3 for guile-devel@gnu.org; Tue, 01 Feb 2011 23:28:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkUKp-0001yY-6O for guile-devel@gnu.org; Tue, 01 Feb 2011 23:28:52 -0500 Original-Received: from mail-yw0-f41.google.com ([209.85.213.41]:33810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkUKo-0001yU-VU for guile-devel@gnu.org; Tue, 01 Feb 2011 23:28:51 -0500 Original-Received: by ywj3 with SMTP id 3so3507431ywj.0 for ; Tue, 01 Feb 2011 20:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SzwHsV9fZvkQfgRDMGKdhdj1RNaTSubVWvX7lWfueOY=; b=sNEMNNeKdc8A1zF9N2u43FJpBwGpzBSs8vXo/YwPbAoHIml3+fLlLGd4k7S6ldZoqB 7bci3jndKTNt57xPPFONLkWZ8YTD1+WHzGPp2+AhAnDmdXgjQplA8yItz6XfdMRhXTfL P/4DWsIgSMdrV/bAILe16f4TaE5fnu/sk+zRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SPKT0HWOXQcNSvZtYt0SPal7k5akk0LH5ZtNEyxb4gvolWysCPxAiScxAiNpUOIzP+ bItfmZAYOKY9DbDrwm3hYroZzXi7arY+jqOmS3ko54/WUm77nwC1iU+5Vb3XfbhCe5H4 uTzb+9OF88l80ez+KfeGrk5J/5ZAEg7kzkt/U= Original-Received: by 10.147.170.14 with SMTP id x14mr12552763yao.36.1296620930436; Tue, 01 Feb 2011 20:28:50 -0800 (PST) Original-Received: by 10.147.136.20 with HTTP; Tue, 1 Feb 2011 20:28:50 -0800 (PST) In-Reply-To: <87aaifuktj.fsf@yeeloong.netris.org> X-Google-Sender-Auth: xD3Vglrif5ksRUKslr4z0jOdJCo X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.213.41 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:11504 Archived-At: Hello Mark, I haven't read through all of the discussion yet, but it's obvious that you have good reasons for wanting (* 0 X) to be NaN when X is inexact. And yet for compatibility reasons it is nice if Guile agrees with Scheme standards. Therefore I think it would be great if you would send an email with exactly what you said here to scheme-reports@scheme-reports.org, which is the public discussion forum for R7RS. Of course Guile could just implement this itself, and maybe it will, but our lives would be much easier if our behavior could be both useful and standard, and it seems that the best way to do that might be to change the standard. Noah On Tue, Feb 1, 2011 at 11:22 PM, Mark H Weaver wrote: > I wrote: >>> Are you following specific references here? =A0FWIW, for cases like thi= s, >>> 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. =A0Sectio= n >> 11.7.4.3 provides the following examples: >> >> =A0 (* 0 +inf.0) =A0=3D=3D> =A00 or +nan.0 >> =A0 (* 0 +nan.0) =A0=3D=3D> =A00 or +nan.0 >> =A0 (* 1.0 0) =A0 =A0 =3D=3D> =A00 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. =A0For 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. =A0That's because their rule requires > only that the same result is returned for all possible substitutions of > _exact_ arguments for the inexact ones. =A0Since the infinities and NaNs > are not exact, they are not considered as possible substitutions. > > =A0One general exception to the rule above is that an implementation may > =A0return an exact result despite inexact arguments if that exact result > =A0would be the correct result for all possible substitutions of exact > =A0arguments for the inexact ones. > > I think that the R6RS is wrong here. =A0As I understand it, the rationale > for the exactness system is to allow the construction of provably > correct programs, despite the existence of inexact arithmetic. =A0One > 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? =A0Is there a reason more important than being able to trust > that exact values are provably correct? > > =A0 =A0Best, > =A0 =A0 Mark > >