hi does anyone know how to find out the size of a bignum?
normally i would do somethign like (truncate (log x 10))
(1+ (truncate (log 123123123 10))) --> 9 because 123123123 is a 9 digit
number.
However, once the bignum is too big to convert to a double float, log
fails.
Error in function BIGNUM::CHECK-EXPONENT:
Too large to be represented as a DOUBLE-FLOAT:
656100000000000000000000000000000000000000000000000000000000000000087480000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000810000000000000000000000000000000000000000000000000000000000000000054
Any ideas?
<·····@rdrop.com> wrote:
>hi does anyone know how to find out the size of a bignum?
>normally i would do somethign like (truncate (log x 10))
>
>(1+ (truncate (log 123123123 10))) --> 9 because 123123123 is a 9 digit
>number.
>
>However, once the bignum is too big to convert to a double float, log
>fails.
How about (ceiling (integer-length x) (log 10 2))?
--
Juho Snellman
that is a great suggestion, thanks.... i'll give it a try.
-jim
Juho Snellman wrote:
> <·····@rdrop.com> wrote:
>
>>hi does anyone know how to find out the size of a bignum?
>>normally i would do somethign like (truncate (log x 10))
>>
>>(1+ (truncate (log 123123123 10))) --> 9 because 123123123 is a 9 digit
>>number.
>>
>>However, once the bignum is too big to convert to a double float, log
>>fails.
>
>
> How about (ceiling (integer-length x) (log 10 2))?
>
Jim Newton <·····@rdrop.com> writes:
> hi does anyone know how to find out the size of a bignum?
> normally i would do somethign like (truncate (log x 10))
...
> However, once the bignum is too big to convert to a double float, log
> fails.
...
> Any ideas?
Complain to your vendor. There's no good reason why the implementation
shouldn't be able to calculate the logarithm of a bignum without
starting by turning it into a double-float.
(defun bignum-digits (n)
"The number of decimal digits in N. Inefficient for large N."
(length (format nil "~A" n)))
(defun bignum-digits (n)
"The number of decimal digits in N. May occasionally be off by 1."
(let* ((m (integer-length n))
(m1 (max 0 (- m 256)))
(n1 (ash n (- m1)))
(log-n (+ (log n1 10)
(* m1 (log 2 10)))))
(1+ (truncate log-n))))
--
Gareth McCaughan
.sig under construc
well it seems like CMUCL cannot handle log of a very large bignum.
it does not upset me very much since i have a nice workaround
thanks to ······@iki.fi. besides all i really needed to know
was the number of digits so i think his suggestion is probably
more efficient anyway. i do not really need the
logarithm, i just need the whole number part of the
logarithm.
(ceiling (integer-length x) (log 10 2))
-jim
Gareth McCaughan wrote:
> Jim Newton <·····@rdrop.com> writes:
>
>
>>hi does anyone know how to find out the size of a bignum?
>>normally i would do somethign like (truncate (log x 10))
>
> ...
>
>>However, once the bignum is too big to convert to a double float, log
>>fails.
>
> ...
>
>>Any ideas?
>
>
> Complain to your vendor. There's no good reason why the implementation
> shouldn't be able to calculate the logarithm of a bignum without
> starting by turning it into a double-float.
>
> (defun bignum-digits (n)
> "The number of decimal digits in N. Inefficient for large N."
> (length (format nil "~A" n)))
>
> (defun bignum-digits (n)
> "The number of decimal digits in N. May occasionally be off by 1."
> (let* ((m (integer-length n))
> (m1 (max 0 (- m 256)))
> (n1 (ash n (- m1)))
> (log-n (+ (log n1 10)
> (* m1 (log 2 10)))))
> (1+ (truncate log-n))))
>
Jim Newton wrote:
> well it seems like CMUCL cannot handle log of a very large bignum.
> it does not upset me very much since i have a nice workaround
> thanks to ······@iki.fi. besides all i really needed to know
* (log (ash 1 10000000))
6931472.0
Get a newer version of cmucl. But of course, the result will only have
single-float accuracy, so it might not be good enough for what you want,
so ······@iki.fi has a good general solution.
Ray
does anyone know a good source to read about bignums?
the lisp books that i have on my shelf talk about
the existance of bignum but do not tell much more
about them.
-jim
Julian Stecklina wrote:
> Raymond Toy <····@earthlink.net> writes:
>
>
>>* (log (ash 1 10000000))
>>6931472.0
>
>
> [1]> (log (ash 1 10000000))
>
> *** - ASH: too large shift amount 10000000
> 1. Break [2]>
>
> on CLISP 2.30
>
> Regards,
Jim Newton <·····@rdrop.com> writes:
> does anyone know a good source to read about bignums?
> the lisp books that i have on my shelf talk about
> the existance of bignum but do not tell much more
> about them.
What sort of information about them do you want?
--
Gareth McCaughan
.sig under construc
well for example some examples of them.
the two problems i had so far were.
1) how to create a bignum. I figured out by trial and error
that there is no need to create one explicitly, if you keep
incrementing or doubling a normal fixnum then it eventually
becomes a bignum automatically. That is easy but was not
obvious to me from reading the documentation. Note that this
is not the case with single and double percision floating point
if you keep dividing a single percision floating point number
by 2 it never automatically becomes a double.
2) how to find out the number of digits. my first attempt
of taking the log failed, for which this newsgroup was
very helpful at thinking of a better solution.
Not sure what other information i'd want to read. but someone
who has experience with them probably has some interesting
stuff to tell. bignums are a nice feature of lisp not
available in any other language that i've ever used.
Gareth McCaughan wrote:
> Jim Newton <·····@rdrop.com> writes:
>
>
>>does anyone know a good source to read about bignums?
>>the lisp books that i have on my shelf talk about
>>the existance of bignum but do not tell much more
>>about them.
>
>
> What sort of information about them do you want?
>
Jim Newton <·····@rdrop.com> writes:
> 1) how to create a bignum. I figured out by trial and error
> that there is no need to create one explicitly, if you keep
> incrementing or doubling a normal fixnum then it eventually
> becomes a bignum automatically.
For integers, you can also use (1+ most-positive-fixnum). For floating
point, I guess you can work with most-positive-double-float and
suchlike, depending on what you want. Have a peek in the HyperSpec at
www.lisp.org for lots of juicy constants.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
Thomas Lindgren <···········@*****.***> wrote:
> Jim Newton <·····@rdrop.com> writes:
>> 1) how to create a bignum. I figured out by trial and error
>> that there is no need to create one explicitly, if you keep
>> incrementing or doubling a normal fixnum then it eventually
>> becomes a bignum automatically.
>
> For integers, you can also use (1+ most-positive-fixnum).
Playing around with this, I found one of those other places where
implementations vary a lot:
(type-of (1+ most-positive-fixnum))
CLISP says: (INTEGER (16777215))
SBCL says: (INTEGER 536870912)
GCL says: BIGNUM
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
"Karl A. Krueger" wrote:
>
> Thomas Lindgren <···········@*****.***> wrote:
> > Jim Newton <·····@rdrop.com> writes:
> >> 1) how to create a bignum. I figured out by trial and error
> >> that there is no need to create one explicitly, if you keep
> >> incrementing or doubling a normal fixnum then it eventually
> >> becomes a bignum automatically.
> >
> > For integers, you can also use (1+ most-positive-fixnum).
>
> Playing around with this, I found one of those other places where
> implementations vary a lot:
>
> (type-of (1+ most-positive-fixnum))
>
> CLISP says: (INTEGER (16777215))
> SBCL says: (INTEGER 536870912)
> GCL says: BIGNUM
TYPE-OF is weird and not terribly useful, particularly on integers.
The GCL behavior here is actually not ANSI compliant (there's
a requirement that (TYPE-OF <positive integer>) be a subtype of
UNSIGNED-BYTE).
CLASS-OF may be more useful.
Paul
On Tue, 10 Aug 2004 17:46:21 +0000 (UTC), "Karl A. Krueger" <········@example.edu> wrote:
> Playing around with this, I found one of those other places where
> implementations vary a lot:
>
> (type-of (1+ most-positive-fixnum))
>
> CLISP says: (INTEGER (16777215))
> SBCL says: (INTEGER 536870912)
> GCL says: BIGNUM
But
(typep (1+ most-positive-fixnum) 'bignum)
should return T on all conforming implementations.
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> But
>
> (typep (1+ most-positive-fixnum) 'bignum)
>
> should return T on all conforming implementations.
No, it is only required to return true (that is, something
other than NIL).
Paul
On Tue, 10 Aug 2004 13:51:45 -0500, Paul Dietz <············@motorola.com> wrote:
> No, it is only required to return true (that is, something other
> than NIL).
Argh!
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Tue, 10 Aug 2004 13:51:45 -0500, Paul Dietz <············@motorola.com> wrote:
>
> > No, it is only required to return true (that is, something other
> > than NIL).
>
> Argh!
That which is not nil is true.
Is there any language besides lisp where something like this would
return true?
(if 0 'true 'false)
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> Is there any language besides lisp where something like this would
> return true?
>
> (if 0 'true 'false)
Scheme. ;)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
David Steuber <·····@david-steuber.com> writes:
> Is there any language besides lisp where something like this would
> return true?
>
> (if 0 'true 'false)
In C, C++, Objective-C: "false"?"t":"nil" returns "t"...
In Ada, Pascal, Modula-2, Modula-3, etc (any sane algo-like language):
if 0 then ret:=true else ret:=false; end;
raises an error at compilation time.
In Smalltalk, unless you add a method to the number class,
0 ifTrue: [ "true" ] ifFalse: [ "false" ] .
generates unimplemented message and eventually an error object.
Ah, and in scheme, AFAIK, (if 0 'true 'false) generates and error
because the condition is neither #t or #f.
It looks like (if 0 'true 'false) --> 'true is a characteristic of lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Pascal Bourguignon <····@mouse-potato.com> writes:
> Ah, and in scheme, AFAIK, (if 0 'true 'false) generates and error
> because the condition is neither #t or #f.
Only joking. Actually (if 0 'true 'false) --> 'true in UMB Scheme.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
has anyone ever fought with Perl over whether something is
true or false? it is really frustrating because some
unexpecteded things are false as it tries to hide the
difference between numbers and strings.
0, (), "" "0" "0.0" i think are all false.
a gotcha is that "0" == "" !!!
i have to admit however that the way python does it is
quite interested. apparently each class in python can define a method
which figures out of a given object of that class is false. further
more you can subclass even the built in classes. i.e., you can
subclass integers and define a method that makes 0 true if you like.
(or make 0 true in the mornings and false in the afternoon :-)
at least that is my understanding of python not being
an expert.
-jim
Pascal Bourguignon wrote:
> David Steuber <·····@david-steuber.com> writes:
>
>>Is there any language besides lisp where something like this would
>>return true?
>>
>>(if 0 'true 'false)
>
>
> In C, C++, Objective-C: "false"?"t":"nil" returns "t"...
>
> In Ada, Pascal, Modula-2, Modula-3, etc (any sane algo-like language):
> if 0 then ret:=true else ret:=false; end;
> raises an error at compilation time.
>
> In Smalltalk, unless you add a method to the number class,
> 0 ifTrue: [ "true" ] ifFalse: [ "false" ] .
> generates unimplemented message and eventually an error object.
>
> Ah, and in scheme, AFAIK, (if 0 'true 'false) generates and error
> because the condition is neither #t or #f.
>
>
>
> It looks like (if 0 'true 'false) --> 'true is a characteristic of lisp.
>
On Thu, 12 Aug 2004 07:21:31 +0200, Jim Newton <·····@rdrop.com> wrote:
> has anyone ever fought with Perl over whether something is true or
> false? it is really frustrating because some unexpecteded things
> are false as it tries to hide the difference between numbers and
> strings.
>
> 0, (), "" "0" "0.0" i think are all false.
"0.0" or "0E0" should be true AFAIR.
> a gotcha is that "0" == "" !!!
That's why Perl also eq. == compares the numbers, eq compares the
strings - go figure.
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Jim Newton <·····@rdrop.com> wrote:
> has anyone ever fought with Perl over whether something is
> true or false? it is really frustrating because some
> unexpecteded things are false as it tries to hide the
> difference between numbers and strings.
>
> 0, (), "" "0" "0.0" i think are all false.
> a gotcha is that "0" == "" !!!
In a dynamically-typed language such as Lisp or Python, a value such as
0 or "0" has a consistent type, such as integer or string, and it is an
error to perform an operation on values of the wrong type. This is not
the case in Perl.
In Perl, the type of a value depends on what operation you are trying to
perform on it. If you use the numeric equality operator ==, Perl tries
to treat the values on either side as numbers. Thus, (0 == "0") is
true. Likewise, if you use the string equality operator eq, Perl tries
to treat the values on either side as strings. Thus, (1 eq "1") is also
true.
In Perl-talk, operators create "context", and values are interpreted
according to context. Some operators, such as the line-reading operator
<>, do very different things in different contexts.
Boolean context is strange. 0 is false. "0" is false. "0foo" is
numerically equal to 0, but is true:
print "falsity\n" if ("0");
print "truth one\n" if ("0foo" == 0);
print "truth two\n" if ("0foo");
... will print both truths.
If Lisp is a dynamically-typed language, perhaps Perl is a demonically-
typed language.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
David Steuber <·····@david-steuber.com> wrote:
> Is there any language besides lisp where something like this would
> return true?
> (if 0 'true 'false)
Ruby, Smalltalk, Haskell, ML, Erlang. Probably tons of others as well.
Only C and its hillbilly cousins don't -- you know where Python and Perl
came from when you hear the accent. Some things can't be hidden by a suit
and new shoes. ;)
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
On Thu, 12 Aug 2004 09:54:33 +0000, nikodemus wrote:
>> Is there any language besides lisp where something like this would
>> return true?
>
>> (if 0 'true 'false)
>
> Ruby, Smalltalk, Haskell, ML, Erlang. Probably tons of others as well.
You are right about Ruby, but in the others it's neither true nor false
but an error.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> On Thu, 12 Aug 2004 09:54:33 +0000, nikodemus wrote:
>
>
>>>Is there any language besides lisp where something like this would
>>>return true?
>>
>>>(if 0 'true 'false)
>>
>>Ruby, Smalltalk, Haskell, ML, Erlang. Probably tons of others as well.
>
> You are right about Ruby, but in the others it's neither true nor false
> but an error.
It's also true in Scheme. See Section 6.3.1 of R5RS.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Marcin 'Qrczak' Kowalczyk wrote:
>
> > On Thu, 12 Aug 2004 09:54:33 +0000, nikodemus wrote:
> >
> >>>Is there any language besides lisp where something like this would
> >>>return true?
> >>
> >>>(if 0 'true 'false)
> >>
> >>Ruby, Smalltalk, Haskell, ML, Erlang. Probably tons of others as well.
> > You are right about Ruby, but in the others it's neither true nor
> > false
> > but an error.
>
> It's also true in Scheme. See Section 6.3.1 of R5RS.
And in Bourne compatible shells.
Bj�rn
David Steuber wrote:
> Edi Weitz <········@agharta.de> writes:
>
>
>>On Tue, 10 Aug 2004 13:51:45 -0500, Paul Dietz <············@motorola.com> wrote:
>>
>>
>>>No, it is only required to return true (that is, something other
>>>than NIL).
>>
>>Argh!
>
>
> That which is not nil is true.
>
> Is there any language besides lisp where something like this would
> return true?
>
> (if 0 'true 'false)
>
Pascal and Ada (I think) would give you a type error. '0' is not a boolean.
Cheers
--
Marco
David Steuber <·····@david-steuber.com> writes:
> Edi Weitz <········@agharta.de> writes:
>
>> On Tue, 10 Aug 2004 13:51:45 -0500, Paul Dietz <············@motorola.com> wrote:
>>
>> > No, it is only required to return true (that is, something other
>> > than NIL).
>>
>> Argh!
>
> That which is not nil is true.
>
> Is there any language besides lisp where something like this would
> return true?
>
> (if 0 'true 'false)
The Bourne shell and its relatives:
$ (if (exit 0); then echo true; else echo false; fi)
true
(even lets me wrap it in parentheses...).
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Jim Newton <·····@rdrop.com> wrote in message news:<··············@uni-berlin.de>...
> ...how to create a bignum. I figured out by trial and error
> that there is no need to create one explicitly, if you keep
> incrementing or doubling a normal fixnum then it eventually
> becomes a bignum automatically.
That's one of the beautiful features of Lisp. The integers really are integers.
Jim Newton <·····@rdrop.com> writes:
> well for example some examples of them.
OK, here's one.
3496263460560236420564052376242934685364516342634263428
Hope that helps :-).
> the two problems i had so far were.
>
> 1) how to create a bignum. I figured out by trial and error
> that there is no need to create one explicitly, if you keep
> incrementing or doubling a normal fixnum then it eventually
> becomes a bignum automatically. That is easy but was not
> obvious to me from reading the documentation. Note that this
> is not the case with single and double precision floating point
> if you keep dividing a single precision floating point number
> by 2 it never automatically becomes a double.
Right. (Though there have been languages in which, e.g.,
if you take the integer 1 and halve it you get a float.)
There's a good reason why floating point numbers shouldn't
behave that way: the difference between single and double
precision is mostly, as the name suggests, about precision
rather than about range. If you multiply two integers and
the result is outside fixnum range, then you *have* to
get a bignum -- what else is there to do? (Yes, I know:
in almost every language other than Lisp, the answer is
"silently return the wrong value". This is a common
answer, but that doesn't stop it being insane.) Whereas
if you have two single-precision floats and multiply them,
you might *want* extra precision but there's no way to
get it: the information just isn't there.
(Pedantic note: The paragraph above is a bit dangerous,
because it might help to perpetuate a common but wrong
idea about floating-point numbers, namely that a
floating-point value is somehow "fuzzy". Really,
a floating-point number is a single number just
as an integer is; it's the arithmetic and other
operations you do with them that are sometimes
fuzzy.)
> 2) how to find out the number of digits. my first attempt
> of taking the log failed, for which this newsgroup was
> very helpful at thinking of a better solution.
Well, you have several solutions now :-). (I still think
that any implementation that won't let you take the log of
a large integer is bad, and should be changed so that it
does let you.)
> Not sure what other information i'd want to read. but someone
> who has experience with them probably has some interesting
> stuff to tell. bignums are a nice feature of lisp not
> available in any other language that i've ever used.
Python has bignums fairly well integrated into the system.
(Not quite as well as in CL, but getting better.)
Java has bignums very poorly integrated into the system.
Perl is more or less on a par with Java here, I think.
There are bignum libraries available for C, C++, etc.
CL is comfortably ahead of the others, though.
Have you encountered CL's rationals yet? Try dividing 1 by 49.
Then multiply the result by 49 again. Try the same thing in
almost any other language you care to mention; you'll get either
0 or something just very slightly smaller than 1. In CL, dividing
1 by 49 just gives you 1/49, and multiplying that by 49 gives 1,
neither more nor less.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> OK, here's one.
>
> 3496263460560236420564052376242934685364516342634263428
>
> Hope that helps :-).
>
yes, clearly that is a bignum, however, i was (and still is not)
clear to me how to make the bignum 0?
0.0 is the single percision float zero
0d0 is the double percision float zero
0 is the fixnum zero,
(complex 0.0 0.0) is the complex zero
but what is the bignum zero?
on the other hand i'm not sure if such a thing exists,
or if it would be useful if it did exist.
-jim
Jim Newton <·····@rdrop.com> writes:
> Gareth McCaughan wrote:
>
>> OK, here's one.
>> 3496263460560236420564052376242934685364516342634263428
>> Hope that helps :-).
>>
>
> yes, clearly that is a bignum, however, i was (and still is not)
> clear to me how to make the bignum 0?
>
> 0.0 is the single percision float zero
> 0d0 is the double percision float zero
> 0 is the fixnum zero,
> (complex 0.0 0.0) is the complex zero
>
> but what is the bignum zero?
> on the other hand i'm not sure if such a thing exists,
> or if it would be useful if it did exist.
There is no such beast. To quote the standard:
The types fixnum and bignum form an exhaustive partition of type
integer.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> Jim Newton <·····@rdrop.com> writes:
>
> > however, i was (and still is not)
> > clear to me how to make the bignum 0?
>
> There is no such beast. To quote the standard:
>
> The types fixnum and bignum form an exhaustive partition of type
> integer.
And this is a good thing. Lisp makes the difference between fixnum
and bignum invisible, as much as possible, so they will act like
integers in a seamless way. 0 and 4785948793785983745897348579357893
are both integers, and that's all I need to know.
[Since this is my second post pushing this ideology, I should add a
disclaimer. In one Lisp project I did, I had to be meticulous about
which integers were really fixnums. Every (dotimes (i n) ...) for
small n included a (declare (fixnum i)) --I had a macro dotimes-f to
add the declaration. I was using CMUCL, whose compiler is great about
suggesting, "I can save you a few cycles at line 10394 if you can tell
me i is really a fixnum".]
Hello,
···············@yahoo.com (Mark McConnell) writes:
> Every (dotimes (i n) ...) for
> small n included a (declare (fixnum i)) --I had a macro dotimes-f to
> add the declaration. I was using CMUCL, whose compiler is great about
> suggesting, "I can save you a few cycles at line 10394 if you can tell
> me i is really a fixnum".
If the compiler does not know that N is FIXNUM, the comparison of I
with N will be inefficient even with your declaration. If fixnumness
of N is known, CMUCL is supposed to derive fixnumness of I. If it does
not... well, cannot speak for CMUCL, but for SBCL I'd post a bug
report.
--
Regards,
Alexey Dejneka
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer
On Wed, 11 Aug 2004 21:12:37 +0200, Jim Newton <·····@rdrop.com> wrote:
> however, i was (and still is not) clear to me how to make the bignum 0?
You can't. An integer is either a fixnum or a bignum but not both.
CLHS entry for system class INTEGER: "The types fixnum and bignum form
an exhaustive partition of type integer." (See glossary entry for
"exhaustive partition.")
Or see the entry for the type BIGNUM: "The type bignum is defined to
be exactly (and integer (not fixnum))."
Cheers,
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Jim Newton <·····@rdrop.com> writes:
> yes, clearly that is a bignum, however, i was (and still is not)
> clear to me how to make the bignum 0?
There is no such thing.
> 0.0 is the single percision float zero
> 0d0 is the double percision float zero
I think it makes sense to think of 0.0 etc. as "zero plus/minus some
small epsilon", and the same with any other float.
> 0 is the fixnum zero,
0, the fixnum, is the only "real" zero.
> (complex 0.0 0.0) is the complex zero
This is not the complex zero, this is the complex with real and
imaginary parts zero plus/minus some epsilon. And 0 being the "real"
zero is manifested by the fact that (complex 0 0) => 0. Which _is_ the
complex zero.
> or if it would be useful if it did exist.
In fact it's extremely useful that "the bignum zero" _doesn't_
exist. In the python language it does exists, and it leads to nothing
but confusion and bugs.
I think it makes sense to think of the floats as more or less "the
rational's evil twins", whose existence is justified "only" by
pragmatic reasons such as hardware support, fixed size, etc. To be
used only with extreme care, by professionals.
Conceptually, CL's numbers are much neater if one just ignores the
floats.
--
Frode Vatvedt Fjeld
Jim Newton <·····@rdrop.com> writes:
[I said:]
>> OK, here's one.
>> 3496263460560236420564052376242934685364516342634263428
>> Hope that helps :-).
[Jim:]
> yes, clearly that is a bignum, however, i was (and still is not)
> clear to me how to make the bignum 0?
As several other people have said, there *is* no "bignum 0".
There is an "integer 0", but it is not a bignum. Bignums and
fixnums are two ways of representing integers, and a Lisp
system will avoid using a bignum when a fixnum will do.
> on the other hand i'm not sure if such a thing exists,
> or if it would be useful if it did exist.
There's an integer 0, and that's all we need. Bignums are
an implementation detail.
--
Gareth McCaughan
.sig under construc
Jim Newton <·····@rdrop.com> writes:
> well it seems like CMUCL cannot handle log of a very large bignum.
> it does not upset me very much since i have a nice workaround
> thanks to ······@iki.fi. besides all i really needed to know
> was the number of digits so i think his suggestion is probably
> more efficient anyway. i do not really need the
> logarithm, i just need the whole number part of the
> logarithm.
> (ceiling (integer-length x) (log 10 2))
That will quite often be wrong by 1. If that's OK for your
application, then I too recommend that solution.
--
Gareth McCaughan
.sig under construc
> * Jim Newton <·····@eqebc.pbz> [2004-08-08 14:00:12 +0200]:
>
> hi does anyone know how to find out the size of a bignum?
> normally i would do somethign like (truncate (log x 10))
>
> (1+ (truncate (log 123123123 10))) --> 9 because 123123123 is a 9 digit
> number.
>
> However, once the bignum is too big to convert to a double float, log
> fails.
>
>
> Error in function BIGNUM::CHECK-EXPONENT:
> Too large to be represented as a DOUBLE-FLOAT:
> 656100000000000000000000000000000000000000000000000000000000000000087480000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000810000000000000000000000000000000000000000000000000000000000000000054
(integer-length X) will return (ceiling (log X 2)) which is the number
of binary digits necessary to record the integer.
thus, the number of decimal digits is
(ceiling (* (integer-length X) (log 2 10)))
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
War doesn't determine who's right, just who's left.
Jim Newton wrote:
> hi does anyone know how to find out the size of a bignum?
> normally i would do somethign like (truncate (log x 10))
>
> (1+ (truncate (log 123123123 10))) --> 9 because 123123123 is a 9 digit
> number.
>
> However, once the bignum is too big to convert to a double float, log
> fails.
>
>
> Error in function BIGNUM::CHECK-EXPONENT:
> Too large to be represented as a DOUBLE-FLOAT:
> 656100000000000000000000000000000000000000000000000000000000000000087480000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000810000000000000000000000000000000000000000000000000000000000000000054
>
>
>
> Any ideas?
>
One obvious one: print the number to a string and check the string length.
Bear