From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: fix for expt bug Date: Sat, 20 Nov 2010 22:49:46 +0100 Message-ID: References: <8762whnc4d.fsf@yeeloong.netris.org> <87r5f4l3yt.fsf@yeeloong.netris.org> <87aalrxim7.fsf@yeeloong.netris.org> <87wrouwf6b.fsf@yeeloong.netris.org> <87bp66rns2.fsf@gnu.org> <87vd4duhi2.fsf@yeeloong.netris.org> <87lj53r09h.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1290289568 29813 80.91.229.12 (20 Nov 2010 21:46:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 20 Nov 2010 21:46:08 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Nov 20 22:46:03 2010 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 1PJvFu-0006Dg-NA for guile-devel@m.gmane.org; Sat, 20 Nov 2010 22:45:59 +0100 Original-Received: from localhost ([127.0.0.1]:53951 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJvFt-0005we-VP for guile-devel@m.gmane.org; Sat, 20 Nov 2010 16:45:58 -0500 Original-Received: from [140.186.70.92] (port=44131 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJvFo-0005vi-7M for guile-devel@gnu.org; Sat, 20 Nov 2010 16:45:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PJvFm-0007H7-Ra for guile-devel@gnu.org; Sat, 20 Nov 2010 16:45:52 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([64.74.157.62]:53388 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PJvFm-0007Gx-NU; Sat, 20 Nov 2010 16:45:50 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7C3E928DF; Sat, 20 Nov 2010 16:46:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=mrdYcAHXGcJ1 Lp+/BN9SIKxMVr4=; b=utzJeF9yULK75fhcKvu009YmmO+c7naR5qzazPLieUKE enCJOTo1cViUX2zowIcq5gr9XS6yO2LXNv5l6r0Bk4ubgz4IQPsSQGAV/3Y4p5cB sY3R1gl8mqpmqJw1A6DFnPBnIqrvBfmxKkK+CN40Z47g6QWHSch6tYeXbSpDmFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=oVobnz sLoVNGTIRBFn+gpcGiJrKBWqonRS95ncI66S5nVQ2LlPp3+Q/CzczoBJ7wYjXVma ULni6R2A//bRZZwWiyijUAfW2M4bGGFmvwjRnfAvo8DaDtk++/mZC2RM/JkSO0la Ca9w8f6RJHLAIjsuOVNMRloQL7utH/I7cUvzE= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 624F628DE; Sat, 20 Nov 2010 16:46:00 -0500 (EST) Original-Received: from unquote.localdomain (unknown [88.0.167.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 7ADEA28DD; Sat, 20 Nov 2010 16:45:58 -0500 (EST) In-Reply-To: <87lj53r09h.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Mon, 08 Nov 2010 22:08:58 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Pobox-Relay-ID: 9088B12E-F4EF-11DF-8F30-B53272ABC92C-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:11172 Archived-At: Hi, On Mon 08 Nov 2010 22:08, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver writes: > >> No, (integer? 3.0) returns #t, as it should, according to R5RS. >> R5RS's description of "integer?" gives this precise example, and >> guile's implementation agrees. > > Damn, I had never realized that, shame on me. Bill Schottstaedt has a nice rant on https://ccrma.stanford.edu/software/snd/snd/s7.html. I think all of his examples are taken from Guile... I can't find the right tone for this section; this is the 400-th revision; I wish I were a better writer! I think the exact/inexact distinction in Scheme is confused and useless, and leads to verbose and buggy code. In some Schemes, "rational" means "could possibly be expressed equally well as a ratio (floats are approximations)". In s7 it's: "is actually expressed as a ratio (or an integer of course)"; otherwise "rational?" is the same as "real?": (not-s7-scheme)> (rational? (sqrt 2)) #t As I understand it, "inexact" originally meant "floating point", and "exact" meant integer or ratio of integers. But words have a life of their own. 0.0 somehow became an "inexact" integer (although it can be represented exactly in floating point). +inf.0 must be an integer =E2=80=94 its fractional part is explicitly zero! But +nan.0... And then there's: (not-s7-scheme)> (integer? 9007199254740993.1) #t When does this matter? I often need to index into a vector, but the index is a float (a "real" in Scheme-speak: its fractional part can be non-zero). In one scheme: (not-s7-scheme)> (vector-ref #(0) (floor 0.1)) ERROR: Wrong type (expecting exact integer): 0.0 ; [why? "it's proba= bly a programmer mistake"!] Not to worry, I'll use inexact->exact: (not-s7-scheme)> (inexact->exact 0.1) ; [why? "floats are = ratios"!] 3602879701896397/36028797018963968 So I end up using the verbose (floor (inexact->exact ...)) everywhere, and even then I have no guarantee that I'll get a legal vector index. When I started work on s7, I thought perhaps "exact" could mean "is represented exactly in the computer". We'd have integers and ratios exact; reals and complex exact if they are exactly represented in the current floating point implementation. 0.0 and 0.5 might be exact if the printout isn't misleading, and 0.1 is inexact. "integer?" and friends would refer instead to the programmer's point of view. That is, if the programmer uses 1 or if the thing prints as 1, it is the integer 1, whereas 1.0 means floating point (not integer!). And to keep exactness in view, we'd have to monitor which operations introduce inexactness =E2=80=94 a kind of interval arithmetic. But then what would inexact->exact do? If we discard the exact/inexact distinction, we can maintain backwards compatibility via: (define exact? rational?) (define (inexact? x) (not (rational? x))) (define inexact->exact rationalize) ; or floor (define (exact->inexact x) (* x 1.0)) There is also Mike Sperber's paper a few years ago about Scheme's numeric tower being borked. Anyway, just to say that you're in good company :) Andy --=20 http://wingolog.org/