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] First batch of numerics changes Date: Thu, 27 Jan 2011 17:06:19 -0500 Message-ID: <87fwse3stg.fsf@yeeloong.netris.org> References: <87lj2762xc.fsf@yeeloong.netris.org> <87tygv4726.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 1296204781 2679 80.91.229.12 (28 Jan 2011 08:53:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 28 Jan 2011 08:53:01 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 28 09:52:58 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 1Pik4e-0001cG-Mc for guile-devel@m.gmane.org; Fri, 28 Jan 2011 09:52:56 +0100 Original-Received: from localhost ([127.0.0.1]:35101 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pik4e-000494-0V for guile-devel@m.gmane.org; Fri, 28 Jan 2011 03:52:56 -0500 Original-Received: from [140.186.70.92] (port=46398 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pijpu-00062P-6t for guile-devel@gnu.org; Fri, 28 Jan 2011 03:37:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pijps-0003Kl-Ks for guile-devel@gnu.org; Fri, 28 Jan 2011 03:37:42 -0500 Original-Received: from world.peace.net ([216.204.32.208]:33547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pijps-0003Kh-HS for guile-devel@gnu.org; Fri, 28 Jan 2011 03:37:40 -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 1PiZz0-0008D6-N2; Thu, 27 Jan 2011 17:06:26 -0500 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1PiZyy-0006Az-Pd; Thu, 27 Jan 2011 17:06:24 -0500 In-Reply-To: <87tygv4726.fsf@yeeloong.netris.org> (Mark H. Weaver's message of "Wed, 26 Jan 2011 17:46:25 -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:11370 Archived-At: I'm having second thoughts about two of the patches: * Patch 0010: `inf?' and `nan?' throw exceptions when applied to non-numbers Previously, these predicates would return #f in that case. I tend to prefer strictness, but perhaps backward compatibility is more important than strictness here. What do you think? * Patch 0018: Exact 0 times infinity or a NaN yields a NaN Previously, exact 0 times anything yields exact 0. This patch makes exact 0 times any _finite_ number yield an exact 0, but makes exact 0 times an infinity or NaN yield a NaN. This is a mistake. A computation involving inexact arguments is permitted to produce an exact answer only if the same answer would be produced regardless of the value of the inexact arguments. R6RS provides these examples, and gives us choices: (* 0 +inf.0) ==> 0 or +nan.0 (* 0 +nan.0) ==> 0 or +nan.0 (* 1.0 0) ==> 0 or 0.0 But the choices are linked. (* 0 n) may produce an exact 0 only if the answer is exact 0 for _any_ value of n (including infinities or NaNs). On the other hand, if we decide that the three cases above should return an exact 0, then we are on mathematically questionable grounds. Consider: (/ 0.0) ==> +inf.0 (required by R6RS) (* 0 +inf.0) ==> 0 (one of two choices, per R6RS) (* 0 (/ 0.0)) ==> 0 (/ 0 0.0) ==> +nan.0 (required by R6RS) The inconsistency of the last two cases does not sit well with me, but in order to eliminate this inconsistency, we must concede that exact 0 times any inexact number must produce an inexact result. I am leaning toward the following: (* 0 +inf.0) ==> +nan.0 (* 0 +nan.0) ==> +nan.0 (* 0 1.0) ==> 1.0 (* 0 0.0) ==> 0.0 What do you think? Mark