From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Neil Jerram" Newsgroups: gmane.lisp.guile.bugs Subject: Re: (< complex) and friends Date: Tue, 12 Aug 2008 10:18:26 +0100 Message-ID: <49dd78620808120218k62cb690aq6251f427fc078a9b@mail.gmail.com> References: <20080811210230.M31889@ccrma.Stanford.EDU> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1218532725 18841 80.91.229.12 (12 Aug 2008 09:18:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Aug 2008 09:18:45 +0000 (UTC) Cc: bug-guile@gnu.org To: "Bill Schottstaedt" Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue Aug 12 11:19:37 2008 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KSq2R-0004v1-VH for guile-bugs@m.gmane.org; Tue, 12 Aug 2008 11:19:36 +0200 Original-Received: from localhost ([127.0.0.1]:53951 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSq1V-0005DX-Gl for guile-bugs@m.gmane.org; Tue, 12 Aug 2008 05:18:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSq1O-0005Am-NH for bug-guile@gnu.org; Tue, 12 Aug 2008 05:18:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSq1M-00056c-GP for bug-guile@gnu.org; Tue, 12 Aug 2008 05:18:29 -0400 Original-Received: from [199.232.76.173] (port=53582 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSq1L-00056K-Vd for bug-guile@gnu.org; Tue, 12 Aug 2008 05:18:28 -0400 Original-Received: from rv-out-0708.google.com ([209.85.198.243]:56795) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KSq1L-00033u-J1 for bug-guile@gnu.org; Tue, 12 Aug 2008 05:18:27 -0400 Original-Received: by rv-out-0708.google.com with SMTP id k29so2612892rvb.6 for ; Tue, 12 Aug 2008 02:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=VWpzcAZodkrqABGOUzt0UrNIuOapVuHOT4mo+aOSJHM=; b=xmwvVGZc9zWVtUSb/7YCmXFvFzD2h6NoaumGx3N0mKDGTEAs3z0W+uKPvMz17Iav5t GFM2B93JOkBhqOOZL18gML0lgIe9dpQKnwnSxgfZHUavBICkfu/uFB7cjW+m1VQClFnr rokQtaVImGLcW+LJkSh4u1lGmDnHP1QA4mqKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=c3MLlBLz3Xomb63uNdMo/6LDAhfK1vf1xHIGsekbiXqnqKdi+KIXjQvLwK6H/vdbbX xIcIvnZkKQQu1+eoB+RFC0t/onueOnHoITSzoax0+BaKuRPb5qsVXlax7OHnkTCaRXbF WczEW5cFU7WNe5V+vgR8E3uTwL0cgnj49fQ4E= Original-Received: by 10.115.76.5 with SMTP id d5mr4497989wal.191.1218532706658; Tue, 12 Aug 2008 02:18:26 -0700 (PDT) Original-Received: by 10.114.197.8 with HTTP; Tue, 12 Aug 2008 02:18:26 -0700 (PDT) In-Reply-To: <20080811210230.M31889@ccrma.Stanford.EDU> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:3964 Archived-At: 2008/8/11 Bill Schottstaedt : > guile> (< 1.0+1.0i) > #t > guile> (< 2.0 1.0+1.0i) > > Backtrace: > In standard input: > 2: 0* [< 2.0 {1.0+1.0i}] > > standard input:2:1: In procedure < in expression (< 2.0 1.0+1.0i): > standard input:2:1: Wrong type: 1.0+1.0i > ABORT: (wrong-type-arg) My guess (without actually looking at the code) is that - using < etc with complex numbers will always give a wrong type arg error - the single arg case is being optimized before reaching the check for a complex number. What behaviour would you prefer? (Perhaps to say that < etc. only compare the real parts of the provided numbers? Is there any precedent for that in other Schemes or standards?) Neil