Difference between EQ and EQL

rpw3@rpw3.org (Rob Warnock) writes:

> 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!!

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 <pitman@nhplace.com> wrote:
+---------------
| rpw3@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@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607