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: Sat, 29 Jan 2011 15:20:37 -0500 Message-ID: <87k4hn31ii.fsf@yeeloong.netris.org> References: <87lj2762xc.fsf@yeeloong.netris.org> <87tygv4726.fsf@yeeloong.netris.org> <87wrlo2k9z.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 1296332480 19085 80.91.229.12 (29 Jan 2011 20:21:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 29 Jan 2011 20:21:20 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jan 29 21:21:16 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 1PjHIH-0006l9-K4 for guile-devel@m.gmane.org; Sat, 29 Jan 2011 21:21:13 +0100 Original-Received: from localhost ([127.0.0.1]:55630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjHIG-0003tc-PP for guile-devel@m.gmane.org; Sat, 29 Jan 2011 15:21:12 -0500 Original-Received: from [140.186.70.92] (port=52970 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjHHx-0003mV-AR for guile-devel@gnu.org; Sat, 29 Jan 2011 15:20:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PjHHv-000438-Up for guile-devel@gnu.org; Sat, 29 Jan 2011 15:20:53 -0500 Original-Received: from world.peace.net ([216.204.32.208]:56119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PjHHv-00041q-9x for guile-devel@gnu.org; Sat, 29 Jan 2011 15:20:51 -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 1PjHHl-0000XU-Om; Sat, 29 Jan 2011 15:20:41 -0500 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1PjHHh-0008FN-Jp; Sat, 29 Jan 2011 15:20:37 -0500 In-Reply-To: (Andy Wingo's message of "Sat, 29 Jan 2011 18:42:20 +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:11408 Archived-At: Andy Wingo writes: >> if (SCM_CELL_TYPE (x) != SCM_CELL_TYPE (y)) >> + return SCM_BOOL_F; > > Doesn't this prevent 1.0+0.0i from being eqv or equal to 1.0 ? No, because 1.0+0.0i never exists in the current code. At the top of numbers.c it says: > /* General assumptions: > * All objects satisfying SCM_COMPLEXP() have a non-zero complex component. and I have found this to be true. scm_c_make_rectangular is the primitive function that creates complex numbers, and it returns a real number if the imaginary part is zero. All other functions call it directly or indirectly. I know this well because I made a patch to allow the creation of complex numbers with inexact 0.0 imaginary part. In fact, I purposefully arranged for (eqv? 1.0+0.0i) to evaluate to #f, for the same reason that (eqv? 0.0 0) evaluates to #f. According to R6RS, a number is real only if its imaginary part is both zero and exact. Therefore, the imaginary part of any real number is an exact 0, otherwise it wouldn't be real. But the imaginary part of 1.0+0.0i is clearly an _inexact_ zero. R6RS explicitly states that eqv? returns #f if one number is exact and the other is inexact. So (eqv? 0.0 0) must be #f, and has been. The only remaining assumption here is that (eqv? z1 z2) works by comparing the real and imaginary parts component-wise using eqv?. If you agree with this, then it follows that any complex number, even one with an inexact zero imaginary part, must be unequal to _any_ real number. However, regardless of whether or not you agree with all this, the fact remains that currently, Guile never creates non-real complex numbers with zero imaginary part. So the patch is safe. Best, Mark