Difference between EQ and EQL

Hi all.
Can anybody tell me the difference between EQ and EQL???
It seems be the same!
Thanks in advance

Roberto

On Wed, 16 Jan 2008 06:05:18 GMT, "Roberto" <pippo@pluto.it> wrote:

> Can anybody tell me the difference between EQ and EQL???

http://www.lispworks.com/documentati.../Body/f_eq.htm
http://www.lispworks.com/documentati...Body/f_eql.htm

> It seems be the same!

CL-USER 1 > (let ((a (1+ most-positive-fixnum))
(b (1+ most-positive-fixnum)))
(list (eq a b) (eql a b)))
;; first element is implementation-dependent
(NIL T)

Edi.

--

European Common Lisp Meeting, Amsterdam, April 19/20, 2008

http://weitz.de/eclm2008/

Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

In article <y8hjj.225475$U01.1433568@twister1.libero.it>,
"Roberto" <pippo@pluto.it> wrote:

> Hi all.
> Can anybody tell me the difference between EQ and EQL???
> It seems be the same!
> Thanks in advance
>
> Roberto

They can be different for numbers and characters.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Edi Weitz <spamtrap@agharta.de> writes:

> On Wed, 16 Jan 2008 06:05:18 GMT, "Roberto" <pippo@pluto.it> wrote:
>
> > Can anybody tell me the difference between EQ and EQL???
>
> http://www.lispworks.com/documentati.../Body/f_eq.htm
> http://www.lispworks.com/documentati...Body/f_eql.htm
>
> > It seems be the same!
>
> CL-USER 1 > (let ((a (1+ most-positive-fixnum))
> (b (1+ most-positive-fixnum)))
> (list (eq a b) (eql a b)))
> ;; first element is implementation-dependent
> (NIL T)

It is for smaller numbers too. Many implementations make them EQ, but
there isn't a requirement to do so. So it's harder to reliably
illustrate the fact of the dependency on implementation. (Likewise, it
is theoretically possible for an implementation to "intern" bignums and
confuse someone even with the above test case.)

R> Can anybody tell me the difference between EQ and EQL???

EQ is like a low level primitive that is meant to work very fast, comparing
only pointer, or something of size of pointer -- constant size.
bignums can be heap-allocated, and it's possible to have two bignum that are
= but have different address.
moreover, implementation is allowed to allocate numbers on heap (boxed) and
on stack/registers (unboxed) and do all kinds of tricks to optimize
operations on numbers
so EQ can work in a weird (implementation dependent) way for numbers (and
also for characters).

EQL fixes this issue -- it always compares contents of numbers.

On 16 Jan 2008 03:05:51 -0500, Kent M Pitman <pitman@nhplace.com> wrote:

> Edi Weitz <spamtrap@agharta.de> writes:
>
>> On Wed, 16 Jan 2008 06:05:18 GMT, "Roberto" <pippo@pluto.it> wrote:
>>
>> > Can anybody tell me the difference between EQ and EQL???
>>
>> http://www.lispworks.com/documentati.../Body/f_eq.htm
>> http://www.lispworks.com/documentati...Body/f_eql.htm
>>
>> > It seems be the same!
>>
>> CL-USER 1 > (let ((a (1+ most-positive-fixnum))
>> (b (1+ most-positive-fixnum)))
>> (list (eq a b) (eql a b)))
>> ;; first element is implementation-dependent
>> (NIL T)
>
> It is for smaller numbers too. Many implementations make them EQ,
> but there isn't a requirement to do so.

Right, that's why I posted the links to the dictionary entries where
amongst other things the OP will find an example for (EQ 3 3) being T
or NIL depending on the implementation. ISTR that ABCL does that, but
I'm not sure.

> (Likewise, it is theoretically possible for an implementation to
> "intern" bignums and confuse someone even with the above test case.)

That's what I meant with the comment in the code.

BTW, is there anything in the ANSI spec that says something about the
behaviour of FIXNUMs? The only thing I could find (I didn't spend
much time, though) is that the type has to be a supertype of
(SIGNED-BYTE 16). Everyhing else is implementation-dependent?

Edi.

--

European Common Lisp Meeting, Amsterdam, April 19/20, 2008

http://weitz.de/eclm2008/

Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

On Jan 16, 8:05 am, "Roberto" <pi...@pluto.it> wrote:
> Hi all.
> Can anybody tell me the difference between EQ and EQL???
> It seems be the same!
> Thanks in advance
>
> Roberto

http://eli.thegreenplace.net/2004/08...ality-in-lisp/

Edi Weitz <spamtrap@agharta.de> writes:

> BTW, is there anything in the ANSI spec that says something about the
> behaviour of FIXNUMs? The only thing I could find (I didn't spend
> much time, though) is that the type has to be a supertype of
> (SIGNED-BYTE 16). Everyhing else is implementation-dependent?

Probably. Actually, there was an implementation that didn't want them
at all, it only wanted bignums. (Not all such implementations made
the light of day--I'm not sure if this one I'm thinking of did. I
vaguely recall it might have been for a CDC 7600 or some such odd
case.) Whoever it was, they just wanted one general-purpose numeric
representation, and they wanted to know if MOST-POSITIVE-FIXNUM could
be NIL since they had no fixnums. There might even be a cleanup issue
that related to this. There were related theoretical questions about
whether if the entire FIXNUM range was positive (e.g., if they were a
subtype of unsigned byte), MOST-NEGATIVE-FIXNUM could be a positive
number. This may be something that prompted the biz about
(SIGNED-BYTE 16) being involved.

At some point, I personally advocated not having FIXNUM at all since
it would have no useful portable meaning. But others said users didn't
care about that and would alarmed if there were no fixnums. It was
simply a checklist item and it didn't matter what they did, just that
they were there for vendors to attach their features to. And that's
what was the winning argument. It was a judgment call and right/wrong
is hard to judge unambiguously, but I'd say probably they were right
that more users were happier than would have been without it, even for
all its lack of specificity. And, for the most part, people who think
it's the wrong thing can generally use a particular INTEGER range or a
SIGNED-BYTE spec or whatever, so everyone's more or less accommodated.
But it was an odd design issue to be sure.

What the `L'?

Edi Weitz <spamtrap@agharta.de> wrote:
+---------------
| BTW, is there anything in the ANSI spec that says something about the
| behaviour of FIXNUMs? The only thing I could find (I didn't spend
| much time, though) is that the type has to be a supertype of
| (SIGNED-BYTE 16). Everyhing else is implementation-dependent?
+---------------

As Kent noted in a parallel, yeah, mostly. EXCEPT...

MOST-POSITIVE-FIXNUM actually must be greater than *both* 2^15 - 1
and ARRAY-DIMENSION-LIMIT ("A positive fixnum, the exact magnitude of
which is implementation-dependent, but which is not less than 1024").
And not only that, but the *product* of all the dimensions of any
array must also be less than ARRAY-TOTAL-SIZE-LIMIT... which *also*
is required to be a FIXNUM!!

So for any "reasonable" CL implementation, you want FIXNUMs to be
as large as feasible, to keep from imposing a limit on the size of
your arrays. This constraint is more severe for arrays of BASE-CHAR
(SIMPLE-BASE-STRINGs), since they're likely to need more subscript
space per megabyte than arrays of LONG-FLOAT, say. ;-}


-Rob

p.s. In 32-bit CMUCL, MOST-POSITIVE-FIXNUM is 536870911, which isn't
normally a issue since by default CMUCL has a limit of 512 MiB on
dynamic space anyway. But you can run it in such a way that it *does*
become an limit:

$ cmucl -dynamic-space-size 1500
...[chatter]...
cmu> (defvar *monster* (make-array 536870910
:element-type '(unsigned-byte 8)))

*MONSTER*
cmu> (room)

Dynamic Space Usage: 543,672,424 bytes (out of 1,500 MB).
Read-Only Space Usage: 20,614,808 bytes (out of 256 MB).
Static Space Usage: 2,968,696 bytes (out of 256 MB).
Control Stack Usage: 484 bytes (out of 128 MB).
Binding Stack Usage: 96 bytes (out of 128 MB).
The current dynamic space is 0.
Garbage collection is currently enabled.

Breakdown for dynamic space:
536,915,976 bytes for 671 simple-array-unsigned-byte-8-type objects.
7,356,408 bytes for 874,654 other objects.
544,272,384 bytes for 875,325 dynamic objects (space total.)

cmu> (defvar *monster2* (make-array 536870911 ; just a *tiny* bit bigger
:element-type '(unsigned-byte 8)))
Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
536870911 is not of type (OR (MOD 536870911) CONS NULL)
[Condition of type TYPE-ERROR]

Restarts:
0: [ABORT] Return to Top-Level.
...[debugger prompt]...

-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607