In article <························@twister1.libero.it>,
"Roberto" <·····@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, ······@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 ***
On Wed, 16 Jan 2008 06:05:18 GMT, "Roberto" <·····@pluto.it> wrote:
> Can anybody tell me the difference between EQ and EQL???
http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm
http://www.lispworks.com/documentation/HyperSpec/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 ·········@agharta.de" 5) "edi")
From: Kent M Pitman
Subject: Re: Difference between EQ and EQL
Date:
Message-ID: <ubq7m2o0w.fsf@nhplace.com>
Edi Weitz <········@agharta.de> writes:
> On Wed, 16 Jan 2008 06:05:18 GMT, "Roberto" <·····@pluto.it> wrote:
>
> > Can anybody tell me the difference between EQ and EQL???
>
> http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm
> http://www.lispworks.com/documentation/HyperSpec/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.)
On 16 Jan 2008 03:05:51 -0500, Kent M Pitman <······@nhplace.com> wrote:
> Edi Weitz <········@agharta.de> writes:
>
>> On Wed, 16 Jan 2008 06:05:18 GMT, "Roberto" <·····@pluto.it> wrote:
>>
>> > Can anybody tell me the difference between EQ and EQL???
>>
>> http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm
>> http://www.lispworks.com/documentation/HyperSpec/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 ·········@agharta.de" 5) "edi")
From: Kent M Pitman
Subject: Re: Difference between EQ and EQL
Date:
Message-ID: <u4pddtl5m.fsf@nhplace.com>
Edi Weitz <········@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.
Edi Weitz <········@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.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kent M Pitman
Subject: Re: Difference between EQ and EQL
Date:
Message-ID: <uodbkxby2.fsf@nhplace.com>
····@rpw3.org (Rob Warnock) writes:
> Edi Weitz <········@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!!
These are intended on constraints on array size, of course, not on 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. ;-}
You might then infer these to push back on FIXNUM, but note that no
implementation is required to signal an error if you exceed those
constraints. It's merely the case that portable programs can't rely
on working where the bounds have been exceeded.
MOST portable programs can't reasonably test these values and then say
"oh, ok, I'll just work in a smaller space then" so mostly this
doesn't really matter a lot. I think people pick implementations
where the bounds are what they like, whether portable or not, and I
think people mostly use these things for discovering the limits of an
implementation.
Then again, THAT might be a motivation for an implementation to care,
since someone might artificially believe the implementatino couldn't
handle larger arrays. Heh...
> 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)))
>
I'm not sure I got the joke here, and don't have a lot of time to
spend on it just this moment, so maybe you can post an explanation for
the sake of both me and others who might be too shy to ask.
I do know, and we knew going in, that there's an issue that with
small-byte-size arrays where the granularity was such that on various
kinds of architectures, the likelihood would be that you could easily
make too many "slots" to index. That was kind of a no-win the way we
specified everything ... If you can find any threshold value n such that
(aref x n) for x being word-sized elements and n being just below the
max value, then (aref x0 n) for x being something with twice as many
elements because they're half as big is sure to lose... Maybe that's what
you were illustrating here, or maybe it was something else.
Kent M Pitman <······@nhplace.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > 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)))
|
| I'm not sure I got the joke here, and don't have a lot of time to
| spend on it just this moment, so maybe you can post an explanation for
| the sake of both me and others who might be too shy to ask.
+---------------
Not a "joke" per se [unless you consider picking the name *MONSTER*
for a really *big* array as a joke -- it wasn't intended as such],
just a small demonstration that if you increase the heap size limit
on CMUCL you *don't* necessarily get to define arrays that big.
+---------------
| I do know, and we knew going in, that there's an issue that with
| small-byte-size arrays where the granularity was such that on various
| kinds of architectures, the likelihood would be that you could easily
| make too many "slots" to index. That was kind of a no-win the way we
| specified everything ... If you can find any threshold value n such that
| (aref x n) for x being word-sized elements and n being just below the
| max value, then (aref x0 n) for x being something with twice as many
| elements because they're half as big is sure to lose... Maybe that's what
| you were illustrating here...
+---------------
Exactly. They went to a lot of trouble to allow "-dynamic-space-size"
*much* bigger than the default 512 MiB but the fixnum size[1] still
doesn't let you have byte arrays bigger than 512 MiB. Some people might
consider this to be a defect or at least an undesirable limitation.
-Rob
[1] Determined by the CMUCL pointer-tagging Lisp object representation,
which uses the low 3 bits but assigns two code points to fixnums,
which means that fixnums end up being signed 30-bit integers, or
29 bits for positive array indices. Some other Lisp implementations
that use pointer-tagging [e.g., MzScheme, for one] have chosen to
allocate fully *half* of the tag codepoints to fixnums, which for
a 32-bit Lisp object results in signed 31-bit fixnums or 30 bits
for positive array indices, or a max byte array size of 1 GiB.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jan 16, 8:05 am, "Roberto" <·····@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/08/equality-in-lisp/
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.