From: Eli Bendersky
Subject: Re: a short article about equality in Lisp (for beginners)
Date:
Message-ID: <cf5oai$pv3@odbk17.prod.google.com>
Peter Seibel wrote:
> "Eli Bendersky" <······@gmail.com> writes:
>
> > I think it will be quite useful to beginners, both to understand
and
> > to serve as a reference. But I'll be glad to get some feedback from
> > the experienced Lisp programmers here. Are there any obvious flops
?
>
> One nit. EQUAL consides non-EQL bit vectors with the same contents to
> be equivalent; you say it only works for strings.
>
> Also, I belive the case with EQ when applied to numbers and
characters
> is even worse than you let on. For instance,
>
> (let ((x 10)) (eq x x)) ==> NIL
>
> is a legal result which is somewhat at odds with how I imagine most
> folks would understand your model of "EQ compares addresses".
What are you basing this on ?
The Hyperspec provides the following example:
(let ((x "Foo")) (eq x x)) => true
(they say true/false when it's open for interpretation platform
dependently)
>When you
> say:
>
> As a rule of thumb don't use eq on numbers and characters, unless
> you really know what you're doing.
>
> you imply that there are some situations where you might want to use
> EQ to compare numbers or characters. It's not clear to me that that's
> ever the case. I can see that if you're *really* concerned about
speed
> you might use EQ in a place where you know you will never be
comparing
> numbers and/or characters but that's different. (Or some folks argue
> for using EQ when applicable to emphasize that there are no numbers
or
> characters involved--e.g. somewhere where only symbols are being
> compared.)
>
On my system (clisp), eq does work correctly on numbers. Therefore,
at least in theory it's possible to use it for some "mad"
optimizations.
That's why I said "unless you really know what you're doing"
From: Matthew Danish
Subject: Re: a short article about equality in Lisp (for beginners)
Date:
Message-ID: <20040808174534.GF15746@mapcar.org>
On Sun, Aug 08, 2004 at 10:36:18AM -0700, Eli Bendersky wrote:
> >
> > (let ((x 10)) (eq x x)) ==> NIL
> >
> > is a legal result which is somewhat at odds with how I imagine most
> > folks would understand your model of "EQ compares addresses".
>
> What are you basing this on ?
> The Hyperspec provides the following example:
>
> (let ((x "Foo")) (eq x x)) => true
Numbers and characters may be copied arbitrarily, strings may not. In
order to call EQ in (let ((x 10)) (eq x x)), the implementation is
permitted to copy the number object representing 10 for each occurrence
of x. Of course, all implementations represent the value of 10 with a
fixnum immediate, so this won't happen. (Isn't the size of a fixnum
guaranteed to be some value, larger than 15 or so, anyway?)
(let ((x 10000000000000000)) (eq x x)) is a more interesting case.
Here, the number is most likely represented by a bignum (on current
implementations). Two bignum objects which are = can have different
addresses, so they are not EQ.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
On 8831 day of my life Matthew Danish wrote:
> (Isn't the size of a fixnum guaranteed to be some value, larger than
> 15 or so, anyway?)
,----[ Constant Variable MOST-POSITIVE-FIXNUM ]
| most-positive-fixnum is that fixnum closest in value to positive
| infinity provided by the implementation, and greater than or equal to
| both 2^15 - 1 and array-dimension-limit.
`----
So fixnum is at least 16-bit number.
--
Ivan Boldyrev
"Assembly of Japanese bicycle require great peace of mind."
From: John Thingstad
Subject: Re: a short article about equality in Lisp (for beginners)
Date:
Message-ID: <opscmtace1pqzri1@mjolner.upc.no>
Usually 23 bits are used. Of these 4 bits are used to spesify the type.
This gives
2^28'th
On Wed, 11 Aug 2004 16:02:52 +0700, Ivan Boldyrev
<···············@cgitftp.uiggm.nsc.ru> wrote:
> On 8831 day of my life Matthew Danish wrote:
>> (Isn't the size of a fixnum guaranteed to be some value, larger than
>> 15 or so, anyway?)
>
> ,----[ Constant Variable MOST-POSITIVE-FIXNUM ]
> | most-positive-fixnum is that fixnum closest in value to positive
> | infinity provided by the implementation, and greater than or equal to
> | both 2^15 - 1 and array-dimension-limit.
> `----
>
> So fixnum is at least 16-bit number.
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: John Thingstad
Subject: Re: a short article about equality in Lisp (for beginners)
Date:
Message-ID: <opscmtbhg8pqzri1@mjolner.upc.no>
sorry 32 bots
Thu, 12 Aug 2004 20:21:38 +0200, John Thingstad
<··············@chello.no> wrote:
> Usually 23 bits are used. Of these 4 bits are used to spesify the type.
> This gives
> 2^28'th
>
> On Wed, 11 Aug 2004 16:02:52 +0700, Ivan Boldyrev
> <···············@cgitftp.uiggm.nsc.ru> wrote:
>
>> On 8831 day of my life Matthew Danish wrote:
>>> (Isn't the size of a fixnum guaranteed to be some value, larger than
>>> 15 or so, anyway?)
>>
>> ,----[ Constant Variable MOST-POSITIVE-FIXNUM ]
>> | most-positive-fixnum is that fixnum closest in value to positive
>> | infinity provided by the implementation, and greater than or equal to
>> | both 2^15 - 1 and array-dimension-limit.
>> `----
>>
>> So fixnum is at least 16-bit number.
>>
>
>
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Peter Seibel
Subject: Re: a short article about equality in Lisp (for beginners)
Date:
Message-ID: <m34qndo0ba.fsf@javamonkey.com>
"Eli Bendersky" <······@gmail.com> writes:
> Peter Seibel wrote:
>> Also, I belive the case with EQ when applied to numbers and
>> characters is even worse than you let on. For instance,
>>
>> (let ((x 10)) (eq x x)) ==> NIL
>>
>> is a legal result which is somewhat at odds with how I imagine most
>> folks would understand your model of "EQ compares addresses".
>
> What are you basing this on ? The Hyperspec provides the following
> example:
>
> (let ((x "Foo")) (eq x x)) => true
>
> (they say true/false when it's open for interpretation platform
> dependently)
Look down a few examples they give this:
(let ((x 5)) (eq x x))
=> true
OR=> false
>>When you say:
>>
>> As a rule of thumb don't use eq on numbers and characters, unless
>> you really know what you're doing.
>>
>> you imply that there are some situations where you might want to
>> use EQ to compare numbers or characters. It's not clear to me that
>> that's ever the case. I can see that if you're *really* concerned
>> about speed you might use EQ in a place where you know you will
>> never be comparing numbers and/or characters but that's different.
>> (Or some folks argue for using EQ when applicable to emphasize that
>> there are no numbers or characters involved--e.g. somewhere where
>> only symbols are being compared.)
>
> On my system (clisp), eq does work correctly on numbers. Therefore,
> at least in theory it's possible to use it for some "mad"
> optimizations. That's why I said "unless you really know what you're
> doing"
Hmmm. Does the CLISP documentation guarantee that? In that case you're
using a platform specific extension if you use EQ to compare numbers.
And if the CLISP documentation doesn't guarantee some specific
behavior vis a vis EQ and numbers then you're just asking for trouble
when a new version of CLISP comes out and happens to change the
behavior that you've observed. You're also asking for trouble in the
sense that while you think you've observed that "eq does work
correctly on numbers" it in fact only works for certain cases that you
happen to have checked out. For intance in CLISP 2.33.2 (the latest
and greatest as far as I know):
(defun foo (x) (eq (1+ x) (1+ x)))
(defun bar (x y) (eq x y))
(foo most-positive-fixnum) ==> NIL
(foo 1.0) ==> NIL
(bar 1.0 1.0) ==> NIL
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp