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] Complex numbers with inexact zero imaginary part, etc Date: Wed, 02 Feb 2011 16:36:34 -0500 Message-ID: <87pqrat8yl.fsf@yeeloong.netris.org> References: <87zkqeu19q.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 1296682667 19494 80.91.229.12 (2 Feb 2011 21:37:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2011 21:37:47 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 02 22:37:42 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 1PkkOR-0007Wx-FJ for guile-devel@m.gmane.org; Wed, 02 Feb 2011 22:37:41 +0100 Original-Received: from localhost ([127.0.0.1]:44596 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkkOO-0002DC-KF for guile-devel@m.gmane.org; Wed, 02 Feb 2011 16:37:36 -0500 Original-Received: from [140.186.70.92] (port=55855 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkkO6-0001rE-ND for guile-devel@gnu.org; Wed, 02 Feb 2011 16:37:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkkNW-0006nm-Vd for guile-devel@gnu.org; Wed, 02 Feb 2011 16:36:48 -0500 Original-Received: from world.peace.net ([216.204.32.208]:38469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkkNW-0006ne-SB for guile-devel@gnu.org; Wed, 02 Feb 2011 16:36:42 -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 1PkkNR-0005Xg-84; Wed, 02 Feb 2011 16:36:37 -0500 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1PkkNO-0001AJ-Ub; Wed, 02 Feb 2011 16:36:34 -0500 In-Reply-To: (Andy Wingo's message of "Wed, 02 Feb 2011 21:30:38 +0100") 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:11520 Archived-At: Andy Wingo writes: >> (scm_difference): (- 0 0.0) now returns -0.0. Previously it returned >> 0.0. Also make sure that (- 0 0.0+0.0i) will return -0.0-0.0i. > > Is this right? I can convince myself both ways. I'm not 100% confident, but I'm pretty sure it's the right thing. As far as I can tell, the semantics of the signed zeroes are based on one-sided limits, so (f 0.0) aka (f +0.0) should be the limit of (f x) as x approaches zero from the right, similarly for (f -0.0) except approaching from the left. (f +inf.0) and (f -inf.0) should also be defined in terms of limits. I don't know how this is handled when more than one of these special values is present in the operand list. As for the rules of when to return 0.0 vs -0.0, I'm not sure. IEEE 754 certainly produces -0.0 when a negative number underflows, but -0.0 is returned in more cases than that. For example, there is no underflow for (+ -0.0 -0.0) or (- 0.0). Based on the rules I know about, the pattern seems to be that if the operation is defined in terms of a limit (i.e. if +0.0, -0.0, +inf.0, or -inf.0 appears as an operand), and the result of the operation is known to approach zero from the left, then -0.0 is returned, otherwise 0.0 is returned. In this case, (- 0 0.0) can be defined as the limit of (- 0 x) as x approaches zero from the right, in which case the result approaches zero from the left. Another argument is that some Schemes apparently take the position that an inexact zero is "weaker" than an exact 0, for example by evaluating (/ 0 0.0) => 0, as pointed out by Aubrey Jaffer in the "Division by zero" section of: http://people.csail.mit.edu/jaffer/III/RAWI In any case, the R6RS explicitly gives these examples, which are widely accepted rules for the signed zeroes: (- 0.0) ==> -0.0 (- 0.0 0.0) ==> 0.0 Therefore, if we decide that (- 0 0.0) should be 0.0 instead of -0.0, then you'll have to change the compiler to no longer change (- x) to (- x 0). Best, Mark