I'm very new to LISP but not to programming, and my main interest is experimental mathematics.
I wanted to know how big the numbers could be for calculation, and I was under the assumption that one could go anywhere as long as the computer didn't crash. It appears that the limit is:
2^2097089 - 1 and any command will overflow beyond that. I just calculated the number of digits roughly in my version of clisp ( 2.48) running on a linux box:
> I'm very new to LISP but not to programming, and my main interest is experimental mathematics.
> I wanted to know how big the numbers could be for calculation, and I was under the assumption that one could go anywhere as long as the computer didn't crash. It appears that the limit is:
> 2^2097089 - 1 and any command will overflow beyond that. I just calculated the > number of digits roughly in my version of clisp ( 2.48) running on a linux box:
> I wanted to know how big the numbers could be for calculation, and I was
> under the assumption that one could go anywhere as long as the computer
> didn't crash. It appears that the limit is:
> 2^2097089 - 1 and any command will overflow beyond that. I just calculated the > number of digits roughly in my version of clisp ( 2.48) running on a linux box:
>> I wanted to know how big the numbers could be for calculation, and I was
>> under the assumption that one could go anywhere as long as the computer
>> didn't crash. It appears that the limit is:
>> 2^2097089 - 1 and any command will overflow beyond that. I just
>> calculated the
>> number of digits roughly in my version of clisp ( 2.48) running on a
>> linux box:
> >> I wanted to know how big the numbers could be for calculation, and I was
> >> under the assumption that one could go anywhere as long as the computer
> >> didn't crash. It appears that the limit is:
> >> 2^2097089 - 1 and any command will overflow beyond that. I just
> >> calculated the
> >> number of digits roughly in my version of clisp ( 2.48) running on a
> >> linux box:
>> >> I wanted to know how big the numbers could be for calculation, and I was
>> >> under the assumption that one could go anywhere as long as the computer
>> >> didn't crash. It appears that the limit is:
>> >> 2^2097089 - 1 and any command will overflow beyond that. I just
>> >> calculated the
>> >> number of digits roughly in my version of clisp ( 2.48) running on a
>> >> linux box:
> On 2012-09-28, Barry Margolin <bar...@alum.mit.edu> wrote:
> > In article <k44gnl$o3...@news.ox.ac.uk>,
> > Ian Clifton <ian.clif...@chem.ox.ac.uk> wrote:
> >> >> I wanted to know how big the numbers could be for calculation, and I was
> >> >> under the assumption that one could go anywhere as long as the computer
> >> >> didn't crash. It appears that the limit is:
> >> >> 2^2097089 - 1 and any command will overflow beyond that. I just
> >> >> calculated the
> >> >> number of digits roughly in my version of clisp ( 2.48) running on a
> >> >> linux box:
> On 2012-09-28, Barry Margolin <bar...@alum.mit.edu> wrote:
> > In article <k44gnl$o3...@news.ox.ac.uk>,
> > Ian Clifton <ian.clif...@chem.ox.ac.uk> wrote:
> >> >> I wanted to know how big the numbers could be for calculation, and I was
> >> >> under the assumption that one could go anywhere as long as the computer
> >> >> didn't crash. It appears that the limit is:
> >> >> 2^2097089 - 1 and any command will overflow beyond that. I just
> >> >> calculated the
> >> >> number of digits roughly in my version of clisp ( 2.48) running on a
> >> >> linux box:
Barry Margolin <bar...@alum.mit.edu> writes:
> In article <20120928140653....@kylheku.com>,
> Kaz Kylheku <k...@kylheku.com> wrote:
>> They are not "bigger", just more, err, "magnitudinous"!
>> Bigger means, strictly, occupying more RAM. :)
> It obviously depends on the context. I'm pretty sure he meant it in the > normal, mathematical sense, in which 10 is bigger than 9.
I suppose it would be possible—not perhaps sensible, but possible—to
have a Lisp implementation whose bignum type had a length which could
expand as necessary beyond integer to itself become a bignum of the same
kind. Such a Lisp could represent any integer, I guess.
>> In article <20120928140653....@kylheku.com>,
>> Kaz Kylheku <k...@kylheku.com> wrote:
>>> They are not "bigger", just more, err, "magnitudinous"!
>>> Bigger means, strictly, occupying more RAM. :)
>> It obviously depends on the context. I'm pretty sure he meant it in the
>> normal, mathematical sense, in which 10 is bigger than 9.
> I suppose it would be possible—not perhaps sensible, but possible—to
> have a Lisp implementation whose bignum type had a length which could
> expand as necessary beyond integer to itself become a bignum of the same
> kind. Such a Lisp could represent any integer, I guess.
Aren't you going to run out of memory long before then? Perhaps there should be bignums with some kind of sparse-byte or runlength encoding.
Ian Clifton <ian.clif...@chem.ox.ac.uk> writes:
> Barry Margolin <bar...@alum.mit.edu> writes:
>> In article <20120928140653....@kylheku.com>,
>> Kaz Kylheku <k...@kylheku.com> wrote:
>>> They are not "bigger", just more, err, "magnitudinous"!
>>> Bigger means, strictly, occupying more RAM. :)
>> It obviously depends on the context. I'm pretty sure he meant it in the >> normal, mathematical sense, in which 10 is bigger than 9.
> I suppose it would be possible—not perhaps sensible, but possible—to
> have a Lisp implementation whose bignum type had a length which could
> expand as necessary beyond integer to itself become a bignum of the same
> kind. Such a Lisp could represent any integer, I guess.
So you don't read the links given to you. Interesting.
Paul Wallich <p...@panix.com> writes:
> On 10/2/12 10:54 AM, Ian Clifton wrote:
>> Barry Margolin <bar...@alum.mit.edu> writes:
>>> In article <20120928140653....@kylheku.com>,
>>> Kaz Kylheku <k...@kylheku.com> wrote:
>>>> They are not "bigger", just more, err, "magnitudinous"!
>>>> Bigger means, strictly, occupying more RAM. :)
>>> It obviously depends on the context. I'm pretty sure he meant it in the
>>> normal, mathematical sense, in which 10 is bigger than 9.
>> I suppose it would be possible—not perhaps sensible, but possible—to
>> have a Lisp implementation whose bignum type had a length which could
>> expand as necessary beyond integer to itself become a bignum of the same
>> kind. Such a Lisp could represent any integer, I guess.
> Aren't you going to run out of memory long before then? Perhaps there
> should be bignums with some kind of sparse-byte or runlength encoding.
Of course. There are a finite number of integers whose lengths are
smaller than the number of particules in the Universe. On the other
hand, there are an infinite number of integers whose lengths are bigger
than the number of particules in the Universe. Such a trivial truth
doesn't seem to be known even by "educated" people. I despair of
humanity.
>>> In article <20120928140653....@kylheku.com>,
>>> Kaz Kylheku <k...@kylheku.com> wrote:
>>>> They are not "bigger", just more, err, "magnitudinous"!
>>>> Bigger means, strictly, occupying more RAM. :)
>>> It obviously depends on the context. I'm pretty sure he meant it in the >>> normal, mathematical sense, in which 10 is bigger than 9.
>> I suppose it would be possible—not perhaps sensible, but possible—to
>> have a Lisp implementation whose bignum type had a length which could
>> expand as necessary beyond integer to itself become a bignum of the same
>> kind. Such a Lisp could represent any integer, I guess.
> So you don't read the links given to you. Interesting.
I did briefly read and enjoy (some of) the links, and I did hint that my
suggestion wasn’t entirely sensible!
-- Ian ◎
>> On 10/2/12 10:54 AM, Ian Clifton wrote:
>>> Barry Margolin <bar...@alum.mit.edu> writes:
>>>> In article <20120928140653....@kylheku.com>,
>>>> Kaz Kylheku <k...@kylheku.com> wrote:
>>>>> They are not "bigger", just more, err, "magnitudinous"!
>>>>> Bigger means, strictly, occupying more RAM. :)
>>>> It obviously depends on the context. I'm pretty sure he meant it in the
>>>> normal, mathematical sense, in which 10 is bigger than 9.
>>> I suppose it would be possible—not perhaps sensible, but possible—to
>>> have a Lisp implementation whose bignum type had a length which could
>>> expand as necessary beyond integer to itself become a bignum of the same
>>> kind. Such a Lisp could represent any integer, I guess.
>> Aren't you going to run out of memory long before then? Perhaps there
>> should be bignums with some kind of sparse-byte or runlength encoding.
> Of course. There are a finite number of integers whose lengths are
> smaller than the number of particules in the Universe. On the other
> hand, there are an infinite number of integers whose lengths are bigger
> than the number of particules in the Universe. Such a trivial truth
> doesn't seem to be known even by "educated" people. I despair of
> humanity.
Paul Wallich <p...@panix.com> writes:
> On 10/2/12 11:21 AM, Pascal J. Bourguignon wrote:
>> Paul Wallich <p...@panix.com> writes:
>>> On 10/2/12 10:54 AM, Ian Clifton wrote:
>>>> Barry Margolin <bar...@alum.mit.edu> writes:
>>>>> In article <20120928140653....@kylheku.com>,
>>>>> Kaz Kylheku <k...@kylheku.com> wrote:
>>>>>> They are not "bigger", just more, err, "magnitudinous"!
>>>>>> Bigger means, strictly, occupying more RAM. :)
>>>>> It obviously depends on the context. I'm pretty sure he meant it in the
>>>>> normal, mathematical sense, in which 10 is bigger than 9.
>>>> I suppose it would be possible—not perhaps sensible, but possible—to
>>>> have a Lisp implementation whose bignum type had a length which could
>>>> expand as necessary beyond integer to itself become a bignum of the same
>>>> kind. Such a Lisp could represent any integer, I guess.
>>> Aren't you going to run out of memory long before then? Perhaps there
>>> should be bignums with some kind of sparse-byte or runlength encoding.
>> Of course. There are a finite number of integers whose lengths are
>> smaller than the number of particules in the Universe. On the other
>> hand, there are an infinite number of integers whose lengths are bigger
>> than the number of particules in the Universe. Such a trivial truth
>> doesn't seem to be known even by "educated" people. I despair of
>> humanity.
> I certainly despair of its sense of humor.
Sorry! I just thought it was interesting that such a scheme could (I
think) be implemented (although you’d have to work out how to do
indexing of data structures by bignum etc), even though we all know it
couldn’t possibly work in any useful sense. I recall that Bart Simpson
once lined up several police bull‐horns, the output of one feeding into
the microphone of the next, in order to produce a stupendously loud
sound. Of course this wouldn’t work either, but you could attempt the
experiment.
Ian Clifton <ian.clif...@chem.ox.ac.uk> writes:
> Sorry! I just thought it was interesting that such a scheme could (I
> think) be implemented (although you’d have to work out how to do
> indexing of data structures by bignum etc), even though we all know it
> couldn’t possibly work in any useful sense. I recall that Bart Simpson
> once lined up several police bull‐horns, the output of one feeding into
> the microphone of the next, in order to produce a stupendously loud
> sound. Of course this wouldn’t work either, but you could attempt the
> experiment.
Well we're speaking of lisp here, so there's a solution. It's easy to
represent a number bigger than the universe in lisp: just use a sexp!
(↑↑↑↑ 3 3)
(↑27↑ 3 3)
(lessp '(↑27↑ 3 3) (add '(↑27↑ 3 3) '(↑↑↑↑ 3 3)))
(defun ↑ (x y) (expt x y))
(defun ↑↑ (x y) (expt x (expt y y)))
(defun ↑↑↑ (x y) (expt x (expt y (expt y y))))
(defun ↑↑↑↑ (x y) (expt x (expt y (expt y (expt y y)))))
(↑↑ 3 3) --> 7625597484987
(↑↑↑ 3 3) can't be computed on current hardware, but you can still
represent this number, as the sexp (↑↑↑ 3 3), like you can represent 100
as: (* (expt 5 2) (expt 2 2)) or some other sexp.
And you can write functions like add and lessp that compute
symbolically. (You can use a theorem prover to implement them).
(defun add (a b)
(cond
((and (numberp a) (numberp b))
(+ a b))
((and (numberp a) (zerop a)) b)
((and (numberp b) (zerop b)) a)
(t `(+ ,a ,b))))
Pascal J. Bourguignon <p...@informatimago.com> wrote:
> (defun ? (x y) (expt x y))
> (defun ?? (x y) (expt x (expt y y)))
> (defun ??? (x y) (expt x (expt y (expt y y))))
> (defun ???? (x y) (expt x (expt y (expt y (expt y y)))))
If you get tired of inventing ????'s (sorry, only ASCII here), notice
that the operator can be generalized for more then 4 ?'s as:
(f (- n 1) x (f n x (- y 1)))
where F is the function implementing the operators and N is the order
of the operator (number of ?'s). See also: hyper operator.
"Pascal J. Bourguignon" <p...@informatimago.com> wrote on Wed, 03 Oct 2012:
> Well we're speaking of lisp here, so there's a solution. It's easy to
> represent a number bigger than the universe in lisp: just use a sexp!
It seems like you're heading down the path of using textual character
representations, to describe big numbers. Surely, before too long,
you'll just follow the standard sequence of such inventions, and wind up
at the usual
busy-beaver(99)
which likely beats any other number you could describe with a similar
small number of characters.
But presumably, people are looking for a representation of a large
integer N, such that the representation is capable of referring to any
of the integers from 1..N.
It kind of changes the problem, if you're just trying to describe (a
few, special) very big numbers in a small number of characters.
-- Don
___________________________________________________________________________ ____
Don Geddis http://don.geddis.org/ d...@geddis.org
You might be an economist if you refuse to sell your children because they
might be worth more later. -- Yoram Bauman
