Does anyone knows the reason of why FIXNUMP is not in the standard?
I can find it, depending on the lisp system in various packages, like
lw::fixnump (Lispworks), or sb-int:fixnump (SBCL), excl:fixnump
(Allegro), system::fixnump (CLISP), and Corman Lisp in the "CL" package..
But why it wasn't included in the standard? I can always do:
(subtypep (type-of ...) 'fixnum)
but this might make certain application generators to leave more code in
the final executable than needed (not a big problem overall, but
checking directly for the given type should be what you have to do).
---------------------------------------------------
A separate question, which looks like to be begging for non-standard
answers (as there is no standard fixnump):
Would this function returns always T:
(fixnump (1- (1+ most-positive-fixnum))) ;;Fix fixnump with your own
version fixnump.
What I mean is, am I guaranteed that if any integer (bignum actually)
after some mathematical operation is able to fit in a fixnum - will it
be actually a fixnum?
Maybe the first question was more clear than my second one.
---------------------------------
Thanks,
Dimiter "malkia" Stanev.
On Feb 5, 5:15 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> Does anyone knows the reason of why FIXNUMP is not in the standard?
>
> I can find it, depending on the lisp system in various packages, like
> lw::fixnump (Lispworks), or sb-int:fixnump (SBCL), excl:fixnump
> (Allegro), system::fixnump (CLISP), and Corman Lisp in the "CL" package..
>
> But why it wasn't included in the standard? I can always do:
>
> (subtypep (type-of ...) 'fixnum)
>
> but this might make certain application generators to leave more code in
> the final executable than needed (not a big problem overall, but
> checking directly for the given type should be what you have to do).
You should probably use typep here, which is more likely to get
optimized that
(subtypep (type-of ...))
> ---------------------------------------------------
>
> A separate question, which looks like to be begging for non-standard
> answers (as there is no standard fixnump):
>
> Would this function returns always T:
>
> (fixnump (1- (1+ most-positive-fixnum))) ;;Fix fixnump with your own
> version fixnump.
>
> What I mean is, am I guaranteed that if any integer (bignum actually)
> after some mathematical operation is able to fit in a fixnum - will it
> be actually a fixnum?
>
> Maybe the first question was more clear than my second one.
>
> ---------------------------------
>
> Thanks,
> Dimiter "malkia" Stanev.
··········@gmail.com wrote:
>
> On Feb 5, 5:15 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
> wrote:
>> Does anyone knows the reason of why FIXNUMP is not in the standard?
>>
>> I can find it, depending on the lisp system in various packages, like
>> lw::fixnump (Lispworks), or sb-int:fixnump (SBCL), excl:fixnump
>> (Allegro), system::fixnump (CLISP), and Corman Lisp in the "CL" package..
>>
>> But why it wasn't included in the standard? I can always do:
>>
>> (subtypep (type-of ...) 'fixnum)
>>
>> but this might make certain application generators to leave more code in
>> the final executable than needed (not a big problem overall, but
>> checking directly for the given type should be what you have to do).
>
> You should probably use typep here, which is more likely to get
> optimized that
> (subtypep (type-of ...))
>
Oh right. I went with subtypep, as I got confused, and I did not check
the CLHS extensively on the issue (lazy me). I've got confused by SBCL
giving me this (type-of 1) -> BIT, and then I thought that I should use
sub-type checking, and probably typep would not work (Actually I forgot
about typep and subtypep, and I was just trying to do something stupid
like (eq 'fixnum (type-of ...)) - which won't work at all).
Thanks, Alex!
On Feb 5, 5:15 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> What I mean is, am I guaranteed that if any integer (bignum actually)
> after some mathematical operation is able to fit in a fixnum - will it
> be actually a fixnum?
I've never heard of an implementation for which this was not the
case. It would be a very odd thing not to do, considering the cost of
bignum allocation, and the relatively small cost of testing for a
fixnum result.
-- Scott
From: Kent M Pitman
Subject: Re: Why there is no standard FIXNUMP?
Date:
Message-ID: <umyqeptok.fsf@nhplace.com>
Scott Burson <········@gmail.com> writes:
> On Feb 5, 5:15 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
> wrote:
> > What I mean is, am I guaranteed that if any integer (bignum actually)
> > after some mathematical operation is able to fit in a fixnum - will it
> > be actually a fixnum?
>
> I've never heard of an implementation for which this was not the
> case. It would be a very odd thing not to do, considering the cost of
> bignum allocation, and the relatively small cost of testing for a
> fixnum result.
It's reasonable to think of common lisp types as sets. So an object
is either in the set or it is not.
But note that the question of whether it's allocated a certain way is
wholly different than the question of whether it's of that type.
In Maclisp, for example, which was not a Common Lisp, but which heavily
influenced CL's definitional wording, some fixnums were heap allocated
and some were not. This is precisely why EQ is not required to work on
integers, so that a pointer to 1 can be equal (under =) to an immediate 1.
The question of what it means to be of a type really is more a
question of whether all the operations on the type are supported. The
only thing CL really says is that there are a number of operations
supported by members of the type FIXNUM. As long as that's not violated,
there's a lot of freedom.
I usually come back to the same question: What possible function could
you be writing that cares? Is this purely an issue of efficiency? Most
cases I can think of where your assumption might be violated are in order
to achieve efficiency, not to violate it. So I would probably write my
code assuming it would be efficient and then report a bug report if it
did not turn out to be.
Also, as discussed in other posts recently, I'm not sure that the spec
requires that fixnums be allocated in machine words at all, such that
the question is also odd in another way... I don't think an implementation
that has a uniform number representation, but that merely identifies a
certain numeric range as fixnums, is prohibited. In such an implementation,
what would the guarantee that Dimiter is soliciting actually imply?
Mostly, the implementations that do different things than you'd expect
do so for a good reason. Implementors willing to take on the task of
making a CL aren't likely to make a risky decision like that for no
good reason. They may be going after a niche that isn't you. Making the
odd case illegal wouldn't make them do it the way you want--it would make
them realize they shouldn't have seen CL as a language to implent for
that niche situation. That wouldn't help our community much.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Scott Burson <········@gmail.com> writes:
>
> > On Feb 5, 5:15 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
> > wrote:
> > > What I mean is, am I guaranteed that if any integer (bignum actually)
> > > after some mathematical operation is able to fit in a fixnum - will it
> > > be actually a fixnum?
> >
> > I've never heard of an implementation for which this was not the
> > case. It would be a very odd thing not to do, considering the cost of
> > bignum allocation, and the relatively small cost of testing for a
> > fixnum result.
>
> It's reasonable to think of common lisp types as sets. So an object
> is either in the set or it is not.
While this is true for most types, CL isn't completely consistent. Some
of the specialized array types are more concerned with representation
than set theory.
And while FIXNUM is defined in terms of the range [most-negative-fixnum,
most-positive-fixnum], the only reason this type even exists is because
it's supposed to be the type that can be represented most efficiently.
--
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 ***
From: Kent M Pitman
Subject: Re: Why there is no standard FIXNUMP?
Date:
Message-ID: <u8x1ytuzj.fsf@nhplace.com>
Barry Margolin <······@alum.mit.edu> writes:
> While this is true for most types, CL isn't completely consistent.
> Some of the specialized array types are more concerned with representation
> than set theory.
>
> And while FIXNUM is defined in terms of the range [most-negative-fixnum,
> most-positive-fixnum], the only reason this type even exists is because
> it's supposed to be the type that can be represented most efficiently.
That's the motivation. But, textually/specificationally, there's no
manifest requirement I can think of ... though you're naturally
welcome to show I'm just spacing out and forgetting one.
As far as I recall, CL does not speak much to efficiency matters or
storage matters. It makes room for implementations to care about such
things, and most do the expected things, but it generally leaves wide
latitude to implementors, leaving it to the market to sort out whether
a given implementation makes an acceptable set of design choices.
Kent M Pitman <······@nhplace.com> wrote:
+---------------
| Barry Margolin <······@alum.mit.edu> writes:
| > And while FIXNUM is defined in terms of the range [most-negative-fixnum,
| > most-positive-fixnum], the only reason this type even exists is because
| > it's supposed to be the type that can be represented most efficiently.
|
| That's the motivation. But, textually/specificationally, there's no
| manifest requirement I can think of ... though you're naturally
| welcome to show I'm just spacing out and forgetting one.
+---------------
Well, there's always the basic restiction that "the type FIXNUM
is required to be a supertype of (SIGNED-BYTE 16)", as well as
the interactions between MOST-POSITIVE-FIXNUM and the various
array limits -- ARRAY-DIMENSION-LIMIT, ARRAY-RANK-LIMIT,
ARRAY-TOTAL-SIZE-LIMIT, etc. -- that we discussed here not all
that long ago.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Kent M Pitman <······@nhplace.com> wrote:
> +---------------
> | Barry Margolin <······@alum.mit.edu> writes:
> | > And while FIXNUM is defined in terms of the range [most-negative-fixnum,
> | > most-positive-fixnum], the only reason this type even exists is because
> | > it's supposed to be the type that can be represented most efficiently.
> |
> | That's the motivation. But, textually/specificationally, there's no
> | manifest requirement I can think of ... though you're naturally
> | welcome to show I'm just spacing out and forgetting one.
> +---------------
>
> Well, there's always the basic restiction that "the type FIXNUM
> is required to be a supertype of (SIGNED-BYTE 16)", as well as
> the interactions between MOST-POSITIVE-FIXNUM and the various
> array limits -- ARRAY-DIMENSION-LIMIT, ARRAY-RANK-LIMIT,
> ARRAY-TOTAL-SIZE-LIMIT, etc. -- that we discussed here not all
> that long ago.
To be fair, those were all after-the-fact requirements that we created.
We had this FIXNUM type in the language (inherited from Maclisp,
Zetalisp, and other dialects), and we were trying to come up with a way
to describe it in a reasonably portable fashion, since the standard
tries hard not to talk about representational issues. We couldn't
imagine any reasonable implementations that wouldn't satisfy those
restrictions (CL is an industrial-strength language, we don't care about
"toy" implementations), so we codified them.
It's certainly possible to create a CL implementation that represents
all integers as boxed, infinite-precision numbers (i.e. bignums), so
that there's no "efficient" range of numbers. In that case, you can
choose your fixnum range pretty arbitrarily. But such an implementation
is not likely to do well in a competitive environment, unless it has
something else really good going for it to make up for this.
--
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 ***
In article <·············@nhplace.com> Kent M
Pitman<······@nhplace.com> wrote:
...
> I usually come back to the same question: What possible function
> could you be writing that cares? Is this purely an issue of
> efficiency? Most cases I can think of where your assumption might be
> violated are in order to achieve efficiency, not to violate it. So I
> would probably write my code assuming it would be efficient and then
> report a bug report if itdid not turn out to be.
Hi Kent,
Yes it's all for efficiency. What I'm doing is reimplementing LUA's
table type:
<http://www.lua.org/source/5.1/ltable.c.html>
My implementation simply uses simple-vector, where in the first
element (0) a hash-table is "stored" for all keys that are less than 1
and bigger than the size of the vector - 1
For now I'm just checking whether rewritting lua-kind of functionality
would bring better results in any of the most common common-lisp
compilers, simply to grasp more knowledge about the low-level
specifics.
Here's what I'm optimizing:
(defun tref (table key)
(declare (type table table))
(if (and (lw:fixnump key)
(< (the fixnum 0) (the fixnum key) (the fixnum (length
table)))) (svref table key)
(gethash key (svref table 0))))
I've originally have written this as:
(defun tref (table key)
(declare (type table table))
(if (and (integerp key)
(< (the integer 0) (the integer key) (the integer (length
table)))) (svref table key)
(gethash key (svref table 0))))
And off course that generates way slower code than the one with fixnum.
So that's basically it :)
FYI, this is my curent implementation, it's still not 100% with the
LUA functionality, but that's the goal:
(defpackage "LUA" (:use "CL")
(:export "MAKE-TABLE" "TREF"))
(in-package "LUA")
(proclaim '(optimize (speed 3) (safety 0) (space 0) (compilation-speed
0) (debug 0)))
;;; Implementation of the LUA table class
;;; For representation we are using just one vector class
;;; Where the first index (0) is a hash-table, used for all keys that
are not positive numbers and 0(deftype table () `simple-vector)
(defun make-table (&optional (array-size 256))
(declare (type (fixnum 1 *) array-size))
(let ((array (make-array array-size)))
(setf (svref array 0) (make-hash-table))
array))
(defun tref (table key)
(declare (type table table))
(if (and (lw:fixnump key)
(< (the fixnum 0) (the fixnum key) (the fixnum (length
table)))) (svref table key)
(gethash key (svref table 0))))
(defun (setf tref) (value table key)
(declare (type table table))
(if (and (lw:fixnump key)
(< (the fixnum 0) (the fixnum key) (the fixnum (length
table)))) (setf (svref table key) value)
(if value
(setf (gethash key (svref table 0)) value)
(remhash key (svref table 0)))))
(defun test-table ()
(let ((table (make-table)))
(setf (tref table 10) 'ten-from-10
(tref table 'ten-to-10) 10)
(format t "(~A, ~A), (~A, ~A)~&"
10 (tref table 10)
'ten-to-10 (tref table 'ten-to-10))))
#+nil
(test-table)
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
Scott Burson <········@gmail.com> writes:
> On Feb 5, 5:15 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
> wrote:
>> What I mean is, am I guaranteed that if any integer (bignum actually)
>> after some mathematical operation is able to fit in a fixnum - will it
>> be actually a fixnum?
>
> I've never heard of an implementation for which this was not the
> case. It would be a very odd thing not to do, considering the cost of
> bignum allocation, and the relatively small cost of testing for a
> fixnum result.
I believe that it would also be a non-conforming CL - the definition
of the integer type says that fixnum and bignum types form an
exhaustive partition of type integer. It also defines fixnum in terms
of the range of its values, bounded by most-negative-fixnum and
most-positive-fixnum. Thus if an operation is perfomed on a bignum
which sends the result into fixnum range, it is by definition a
fixnum.
--
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
Den Tue, 05 Feb 2008 17:15:05 -0800 skrev Dimiter \"malkia\" Stanev:
> Would this function returns always T:
>
> (fixnump (1- (1+ most-positive-fixnum))) ;;Fix fixnump with your own
> version fixnump.
>
> What I mean is, am I guaranteed that if any integer (bignum actually)
> after some mathematical operation is able to fit in a fixnum - will it
> be actually a fixnum?
The wording in http://www.lisp.org/HyperSpec/Body/typ_fixnum.html is a
bit unclear on that issues. I'd say, however, that "Exactly which
integers are fixnums is implementation-defined" gives enough leeway to
the implementation that this is not necessarily the case.
Cheers,
Maciej
Maciej Katafiasz wrote:
> Den Tue, 05 Feb 2008 17:15:05 -0800 skrev Dimiter \"malkia\" Stanev:
>
>> Would this function returns always T:
>>
>> (fixnump (1- (1+ most-positive-fixnum))) ;;Fix fixnump with your own
>> version fixnump.
>>
>> What I mean is, am I guaranteed that if any integer (bignum actually)
>> after some mathematical operation is able to fit in a fixnum - will it
>> be actually a fixnum?
>
> The wording in http://www.lisp.org/HyperSpec/Body/typ_fixnum.html is a
> bit unclear on that issues. I'd say, however, that "Exactly which
> integers are fixnums is implementation-defined" gives enough leeway to
> the implementation that this is not necessarily the case.
>
> Cheers,
> Maciej
I haven't read that portion of CLHS, so thanks for it.
It looks like FIXNUM is not well defined (or kind of for signed 16 bit
integers), but with the implementations I'm using it works with the
example above, I'm just not sure that it would work for any that I've
missed (OR maybe I need to stop worry about that detail :), and do more
coding)
Thanks,
Maciej!