I notice that EQ works on small natnums but not on very big ones.
(11-) (EQ 100000000 100000000)
T
(12-) (EQ 1000000000 1000000000)
[]
What is the cut-off point and is it implementation dependent?
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> I notice that EQ works on small natnums but not on very big ones.
Yes, but you shouldn't rely on it to work on numbers at all. Use EQL.
> What is the cut-off point and is it implementation dependent?
I guess you really want to ask "What's the largest positive fixnum?".
And the answer is: It is implementation-dependent and given by the
constant MOST-POSITIVE-FIXNUM.
--
(espen)
On 9 May, 12:56, Espen Vestre <····@vestre.net> wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > I notice that EQ works on small natnums but not on very big ones.
>
> Yes, but you shouldn't rely on it to work on numbers at all. Use EQL.
>
> > What is the cut-off point and is it implementation dependent?
>
> I guess you really want to ask "What's the largest positive fixnum?".
> And the answer is: It is implementation-dependent and given by the
> constant MOST-POSITIVE-FIXNUM.
> --
> (espen)
OK; I've found CLHS
The effect is that Common Lisp makes no guarantee that eq is true even
when both its arguments are ``the same thing'' if that thing is a
character or number.
OK; this is just for compiler optimisation.
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> On 9 May, 12:56, Espen Vestre <····@vestre.net> wrote:
>> Mark Tarver <··········@ukonline.co.uk> writes:
>> > I notice that EQ works on small natnums but not on very big ones.
>>
>> Yes, but you shouldn't rely on it to work on numbers at all. Use EQL.
>>
>> > What is the cut-off point and is it implementation dependent?
>>
>> I guess you really want to ask "What's the largest positive fixnum?".
>> And the answer is: It is implementation-dependent and given by the
>> constant MOST-POSITIVE-FIXNUM.
>> --
>> (espen)
>
> OK; I've found CLHS
>
> The effect is that Common Lisp makes no guarantee that eq is true even
> when both its arguments are ``the same thing'' if that thing is a
> character or number.
Correct. For one insight into this issue, see:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/9ce970934f784a69/5a6279ea2b3a271a?lnk=gst&q=EQ+cray+Duane+Rettig&rnum=1&hl=en#5a6279ea2b3a271a
Of course, the above article dealt with cons cell lisp-values, but any
lisp-tagged word might have the same issue; for example, if we had
decided on the Cray not to normalize fixnums to propagate the sign bit
into the unused locations, a one-instruction EQ test would not have
worked on two values which had the fixnum tag and the same bits in the
magnitude section (and thus should be considered EQL), but in fact
were not EQ.
> OK; this is just for compiler optimisation.
Exactly. It's good for little else.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On 9 May, 12:56, Espen Vestre <····@vestre.net> wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > I notice that EQ works on small natnums but not on very big ones.
>
> Yes, but you shouldn't rely on it to work on numbers at all. Use EQL.
>
> > What is the cut-off point and is it implementation dependent?
>
> I guess you really want to ask "What's the largest positive fixnum?".
> And the answer is: It is implementation-dependent and given by the
> constant MOST-POSITIVE-FIXNUM.
> --
> (espen)
Actually looking at CLTL, it says little the role of MOST-POSITIVE-
FIXNUM. I do find it does interact with EQ (on SBCL) because natnums
<= MOST-POSITIVE-FIXNUM are compared correctly w.r.t. equality and
natnums > MOST-POSITIVE-FIXNUM are not compared correctly. Is MOST-
POSITIVE-FIXNUM here then, in part, to allow EQ optimisations, where
we are comparing natnums of a modest size? Or does this just work
for SBCL?
Or is MOST-POSITIVE-FIXNUM used to determine a type of number for
compiler directives to THE? I'd guess that FIXNUMs are stored more
efficiently than none FIXNUMs and knowing this can lead to
optimisations in the obect code.
Mark
OK; this is a fast thread! Some replies are anticipating my
questions :)
Mark
On 9 May, 13:30, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 9 May, 12:56, Espen Vestre <····@vestre.net> wrote:
>
> > Mark Tarver <··········@ukonline.co.uk> writes:
> > > I notice that EQ works on small natnums but not on very big ones.
>
> > Yes, but you shouldn't rely on it to work on numbers at all. Use EQL.
>
> > > What is the cut-off point and is it implementation dependent?
>
> > I guess you really want to ask "What's the largest positive fixnum?".
> > And the answer is: It is implementation-dependent and given by the
> > constant MOST-POSITIVE-FIXNUM.
> > --
> > (espen)
>
> Actually looking at CLTL, it says little the role of MOST-POSITIVE-
> FIXNUM. I do find it does interact with EQ (on SBCL) because natnums
> <= MOST-POSITIVE-FIXNUM are compared correctly w.r.t. equality and
> natnums > MOST-POSITIVE-FIXNUM are not compared correctly. Is MOST-
> POSITIVE-FIXNUM here then, in part, to allow EQ optimisations, where
> we are comparing natnums of a modest size? Or does this just work
> for SBCL?
>
> Or is MOST-POSITIVE-FIXNUM used to determine a type of number for
> compiler directives to THE? I'd guess that FIXNUMs are stored more
> efficiently than none FIXNUMs and knowing this can lead to
> optimisations in the obect code.
>
> Mark
Espen Vestre <·····@vestre.net> wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
>
> > I notice that EQ works on small natnums but not on very big ones.
>
> Yes, but you shouldn't rely on it to work on numbers at all. Use EQL.
>
> > What is the cut-off point and is it implementation dependent?
>
> I guess you really want to ask "What's the largest positive fixnum?".
> And the answer is: It is implementation-dependent and given by the
> constant MOST-POSITIVE-FIXNUM.
Using gcl:
>(eq 1023 1023)
T
>(eq 1024 1024)
NIL
>most-positive-fixnum
2147483647
gcl here clearly takes advantage of freedom given to implementations
by Ansi spec.
--
Waldek Hebisch
·······@math.uni.wroc.pl
From: Christian Haselbach
Subject: Re: maximum size for EQ on natural numbers
Date:
Message-ID: <f1vsb1$2fj$1@online.de>
Waldek Hebisch wrote:
> gcl here clearly takes advantage of freedom given to implementations
> by Ansi spec.
To quote their website "While GCL was originally designed to meet the
CLtL1 standard, recent development has brought GCL much of the way
toward its current goal -- full ANSI compliance."
This is from August, 2004, and if their news section is any indication,
approximation of the goal stopped one year later.
Regards,
Christian
Christian Haselbach <······@muon.de> wrote:
> Waldek Hebisch wrote:
> > gcl here clearly takes advantage of freedom given to implementations
> > by Ansi spec.
>
> To quote their website "While GCL was originally designed to meet the
> CLtL1 standard, recent development has brought GCL much of the way
> toward its current goal -- full ANSI compliance."
>
> This is from August, 2004, and if their news section is any indication,
> approximation of the goal stopped one year later.
>
GCL clearly has problems making new release but AFAIK developement is
going (slowly) all the time. I would guess that updating news has
lower priority than developement.
--
Waldek Hebisch
·······@math.uni.wroc.pl
On Wed, 09 May 2007 13:49:37 +0200, Mark Tarver
<··········@ukonline.co.uk> wrote:
> I notice that EQ works on small natnums but not on very big ones.
>
> (11-) (EQ 100000000 100000000)
> T
>
> (12-) (EQ 1000000000 1000000000)
> []
>
> What is the cut-off point and is it implementation dependent?
>
> Mark
>
The short answer is use eql to compare values.
The longer one is:
well a fixnum is stored on the stack usually.
It must fit in the integer size - tag bits. implementation dependent
29 bits is normal
so 2^29-1 is the max number in this example.
If not is is a bignum and stored on the heap.
This is the case in the second example.
In this implementation it thus stores two bignums but not with
the same address. eq compares the addresses of values not
the values themselves. except for fixnum sized integer which
code the value directly on the stack.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On May 9, 1:03 pm, "John Thingstad" <··············@chello.no> wrote:
> well a fixnum is stored on the stack usually.
> It must fit in the integer size - tag bits. implementation dependent
> 29 bits is normal
16 bits is the lower limit for conforming implmentations.
fixnums do not have to compare EQ however.
(message (Hello 'Mark)
(you :wrote :on '(9 May 2007 04:49:37 -0700))
(
MT> What is the cut-off point and is it implementation dependent?
even single implementation might not have single cut-off -- it can depend if
it's compiled or interpreted code, where this number is contained etc. use
EQL to compare numbers.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")
On 9 May, 20:15, Stefan Mandl <············@informatik.uni-
erlangen.de> wrote:
> Hi Mark,
>
> I saw some recommendations to use EQL to compare numbers ... why not = ;)
>
> -- Stefan
Indeed, I'm begun some optimisations that will incrementally push Qi
performance forwards. I wanted to check on the EQ/EQL distinction
w.r.t. to small natnums because EQ is rated as the fastest
comparator. But it seem EQL is the way togo.
The next few releases will be interesting for people into Lisp
compiler optimisations - nuff said ;)
Mark Tarver <··········@ukonline.co.uk> writes:
> Indeed, I'm begun some optimisations that will incrementally push Qi
> performance forwards. I wanted to check on the EQ/EQL distinction
> w.r.t. to small natnums because EQ is rated as the fastest
> comparator. But it seem EQL is the way togo.
If you know that the arguments are natural numbers, you can just as
well use =, as one poster suggested. If they have mixed datatypes, and
you know little about them, you can probably rely on EQL working
faster than <home-rolled-test>+EQ.
--
(espen)
On 9 May, 20:15, Stefan Mandl <············@informatik.uni-
erlangen.de> wrote:
> Hi Mark,
>
> I saw some recommendations to use EQL to compare numbers ... why not = ;)
>
> -- Stefan
= does not allows the comparison of a number with a non-number. But
in specific situtations with the appropriate type guarantees - it
would be a good choice.
Mark
Hi Mark and all others,
> = does not allows the comparison of a number with a non-number. But
> in specific situtations with the appropriate type guarantees - it
> would be a good choice.
I don't want to start the good'ol "{EQL,EQUAL} Considered Harmful" discussion,
so let's try to answer your original question.
=================
In sbcl, openmcl, and clisp on a not so new G4:
noname:~ mandl$ sbcl
This is SBCL 1.0.2, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* MOST-POSITIVE-FIXNUM
536870911
* (eq 536870911 536870911)
T
* (eq 536870912 536870912)
NIL
* (quit)
noname:~ mandl$ openmcl
Welcome to OpenMCL Version 1.0-p060223 (DarwinPPC32)!
? MOST-POSITIVE-FIXNUM
536870911
? (eq 536870911 536870911)
T
? (eq 536870912 536870912)
NIL
? (quit)
noname:~ mandl$ clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
[1]> MOST-POSITIVE-FIXNUM
16777215
[2]> (eq 16777215 16777215)
T
[3]> (eq 16777216 16777216)
NIL
[4]>
=======================
so, the recommendation to consider the MOST-POSITIVE-FIXNUM as cut-off point
seems to be a good heuristic, at least for my setup, and yes, this value is
implementation dependent.
-- Stefan
Stefan Mandl <············@informatik.uni-erlangen.de> writes:
> I saw some recommendations to use EQL to compare numbers ... why not = ;)
(= 1 1.0 1.0e0 1.0d0) is true.
EQL can compare numbers with anything else, [(= NIL 0) returns NIL],
and (EQL 1 1.0) is false.
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.