Hey,
I ran into problems with the LOG function in CL. I was using LispWorks,
and after realizing that some basic support for bignum arithmatic is
weak...I'd even call it broken.
LispWorks:
CL-USER 1 > (log (expt 2 1024) 2)
+1D++0 #| +1D++0 is double-float plus-infinity |#
ACL:
CL-USER(1): (log (expt 2 1024) 2)
Error: This integer is too large to be converted to a double-float:
179769313486231590772930519078902473361797697894230657273430081157732675\
8055009631327084773224075360211201138798713933576587897688144166224928474306394\
7412437776789342486548527630221960124609411945308295208500576883815068234246288\
1473913110540827237163350510684586298239947245938479716304835356329624224137216
[condition type: SIMPLE-ERROR]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart).
1: Abort entirely from this process.
[1] CL-USER(2):
ECL:
> (log (expt 2 1024) 2)
Not a number.
Broken at LOG.
>>
Of the implementations that I tried, only CLISP gets it right:
CLISP:
> (log (expt 2 1024) 2)
1024
>
Some of the above results are embarrassing. Even M-x calc gets it
right, no problem.
I'd even be happy if this returned 2.0, or even 1.999999 etc.
Lisps should be better than this.
dave
On 12/10/02 5:45 PM, in article ···············@nerd-xing.mit.edu, "Dave
Bakhash" <·····@alum.mit.edu> wrote:
> Hey,
>
> I ran into problems with the LOG function in CL. I was using LispWorks,
> and after realizing that some basic support for bignum arithmatic is
> weak...I'd even call it broken.
>
> LispWorks:
>
> CL-USER 1 > (log (expt 2 1024) 2)
> +1D++0 #| +1D++0 is double-float plus-infinity |#
>
> ACL:
>
> CL-USER(1): (log (expt 2 1024) 2)
> Error: This integer is too large to be converted to a double-float:
> 179769313486231590772930519078902473361797697894230657273430081157732675\
> 805500963132708477322407536021120113879871393357658789768814416622492847430639
> 4\
> 741243777678934248654852763022196012460941194530829520850057688381506823424628
> 8\
>
147391311054082723716335051068458629823994724593847971630483535632962422413721>
6
> [condition type: SIMPLE-ERROR]
>
> Restart actions (select using :continue):
> 0: Return to Top Level (an "abort" restart).
> 1: Abort entirely from this process.
> [1] CL-USER(2):
>
> ECL:
>
>> (log (expt 2 1024) 2)
> Not a number.
> Broken at LOG.
>>>
>
> Of the implementations that I tried, only CLISP gets it right:
>
> CLISP:
>
>> (log (expt 2 1024) 2)
> 1024
>>
I tried it on the demo version of Macintosh Common Lisp and, after a long
delay, I got 1024. So I tried OpenMCL, which immediately returned 1047. This
is very strange since those two implementations supposedly use the same code
for math. I started thinking that the commercial version might have it's own
software FP library that's slower but more accurate than the on-chip FP. So
I tried Clisp which immediately returned 1024. Now I'm *really* stumped.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
In article <······················@fastq.com>, Chris Gehlker <·······@fastq.com> wrote:
> I tried it on the demo version of Macintosh Common Lisp and, after a long
> delay, I got 1024.
A long delay? That's odd.
Welcome to Macintosh Common Lisp Version 5.0!
? (time (log (expt 2 1024) 2))
(LOG (EXPT 2 1024) 2) took 1 milliseconds (0.001 seconds) to run.
96 bytes of memory allocated.
1024.0
On 12/10/02 8:19 PM, in article ·····················@solg4.keke.org,
"Takehiko Abe" <····@mac.mac.com> wrote:
> In article <······················@fastq.com>, Chris Gehlker
> <·······@fastq.com> wrote:
>
>> I tried it on the demo version of Macintosh Common Lisp and, after a long
>> delay, I got 1024.
>
> A long delay? That's odd.
>
> Welcome to Macintosh Common Lisp Version 5.0!
> ? (time (log (expt 2 1024) 2))
> (LOG (EXPT 2 1024) 2) took 1 milliseconds (0.001 seconds) to run.
> 96 bytes of memory allocated.
> 1024.0
Now it's instantaneous.
Welcome to the demo version of Macintosh Common Lisp Version 4.3.5!
? (time (log (expt 2 1024) 2))
(LOG (EXPT 2 1024) 2) took 0 milliseconds (0.000 seconds) to run.
96 bytes of memory allocated.
1024.0
? (time (log (expt 2 1024) 2))
(LOG (EXPT 2 1024) 2) took 0 milliseconds (0.000 seconds) to run.
96 bytes of memory allocated.
1024.0
Before it seemed to take 3 - 5 seconds. Some strangeness w/ OS9 memory
management I guess.
The whole IDE seems a bit sluggish. Does version 5 fix this?
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
On Tue, 10 Dec 2002 21:14:16 -0700, Chris Gehlker <·······@fastq.com> wrote:
>On 12/10/02 8:19 PM, in article ·····················@solg4.keke.org,
>"Takehiko Abe" <····@mac.mac.com> wrote:
>> A long delay? That's odd.
>>
>> Welcome to Macintosh Common Lisp Version 5.0!
>> ? (time (log (expt 2 1024) 2))
>> (LOG (EXPT 2 1024) 2) took 1 milliseconds (0.001 seconds) to run.
>> 96 bytes of memory allocated.
>> 1024.0
>
>Now it's instantaneous.
I assume it could be doing the calculation at compile time and so would execute
in no time. I think MCL always compiles everything, and compile time is
typically not figured into the value TIME returns. On the other hand, it is easy
enough to optimize for this case (integer logs, log base 2 especially) to make
this very quick.
On 12/11/02 2:19 AM, in article ··················@news.sf.sbcglobal.net,
"Roger Corman" <·····@corman.net> wrote:
> I assume it could be doing the calculation at compile time and so would
> execute
> in no time. I think MCL always compiles everything, and compile time is
> typically not figured into the value TIME returns. On the other hand, it is
> easy
> enough to optimize for this case (integer logs, log base 2 especially) to make
> this very quick.
This sounds right. I know OpenMCL works that way. I suspect the delay that
shows up occasionally has nothing to do with Lisp per se and everything to
do with how the Blue Box runs.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
In article <······················@fastq.com>, Chris Gehlker <·······@fastq.com> wrote:
> The whole IDE seems a bit sluggish. Does version 5 fix this?
>
You mean slow? I didn't feel it (4.3.5) slow.
Increasing memory partition might help.
4.3.5 is not stable when run under OS9.1. (It turned out that
the unstability is caused by the combination of OS9.1 and
CarbonLib.) So if you happen to have 9.1, you should update it
to 9.2. (btw MCL4.3.1 works fine under 9.1, because it does
not use CarbonLib).
MCL 5.0b is excellent. It seems that the most of the hard part
of the porting job had been done by Digitool. I had my doubts
before, but now that I've used it for a while, I can recommend
it with confidence.
Chris Gehlker <·······@fastq.com> writes:
> I tried it on the demo version of Macintosh Common Lisp and, after a
> long delay, I got 1024. So I tried OpenMCL, which immediately returned
> 1047. This is very strange since those two implementations supposedly
> use the same code for math. I started thinking that the commercial
> version might have it's own software FP library that's slower but more
> accurate than the on-chip FP. So I tried Clisp which immediately
> returned 1024. Now I'm *really* stumped.
Well, I'd probably rather have 1047 than postitive infinity (it's closer
to the answer :-)
Besides that, I've heard that OpenMCL uses some Gnu libs for such
things, whereas MCL does not.
dave
On 12/12/02 11:07 AM, in article ···············@biohazard-cafe.mit.edu,
"Dave Bakhash" <·····@alum.mit.edu> wrote:
> Besides that, I've heard that OpenMCL uses some Gnu libs for such
> things, whereas MCL does not.
Well that explains it. Thanks.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Dave Bakhash <·····@alum.mit.edu> writes:
> Chris Gehlker <·······@fastq.com> writes:
>
> > I tried it on the demo version of Macintosh Common Lisp and, after a
> > long delay, I got 1024. So I tried OpenMCL, which immediately returned
> > 1047. This is very strange since those two implementations supposedly
> > use the same code for math. I started thinking that the commercial
> > version might have it's own software FP library that's slower but more
> > accurate than the on-chip FP. So I tried Clisp which immediately
> > returned 1024. Now I'm *really* stumped.
>
> Well, I'd probably rather have 1047 than postitive infinity (it's closer
> to the answer :-)
Why? I would much prefer a wrong answer that is trivially wrong then
one that looks good, it is easier to deal with a mistake I know about.
marc
Marc Spitzer <········@optonline.net> writes:
> > Well, I'd probably rather have 1047 than postitive infinity (it's
> > closer to the answer :-)
>
> Why? I would much prefer a wrong answer that is trivially wrong then
> one that looks good, it is easier to deal with a mistake I know about.
well, that's partially true, I suppose, except that you have to consider
this:
LispWorks:
CL-USER 1 > (setq x (log (expt 2 1024) 2))
+1D++0 #| +1D++0 is double-float plus-infinity |#
CL-USER 2 > (/ x x)
1D+-0 #| 1D+-0 is double-float not-a-number |#
CL-USER 3 > (- x x)
1D+-0 #| 1D+-0 is double-float not-a-number |#
versus this (simulated OpenMCL):
CL-USER 1 > (setq x (log (expt 2 1024) 2))
1047
CL-USER 2 > (/ x x)
1
CL-USER 3 > (- x x)
0
--dave
Dave Bakhash <·····@alum.mit.edu> writes:
> Marc Spitzer <········@optonline.net> writes:
>
> > > Well, I'd probably rather have 1047 than postitive infinity (it's
> > > closer to the answer :-)
> >
> > Why? I would much prefer a wrong answer that is trivially wrong then
> > one that looks good, it is easier to deal with a mistake I know about.
>
> well, that's partially true, I suppose, except that you have to consider
> this:
>
> LispWorks:
>
> CL-USER 1 > (setq x (log (expt 2 1024) 2))
> +1D++0 #| +1D++0 is double-float plus-infinity |#
>
> CL-USER 2 > (/ x x)
> 1D+-0 #| 1D+-0 is double-float not-a-number |#
>
> CL-USER 3 > (- x x)
> 1D+-0 #| 1D+-0 is double-float not-a-number |#
>
> versus this (simulated OpenMCL):
>
> CL-USER 1 > (setq x (log (expt 2 1024) 2))
> 1047
>
> CL-USER 2 > (/ x x)
> 1
>
or
(/ 1024 x)
1024/1047 ; should be 1
> CL-USER 3 > (- x x)
> 0
(- 1024 x)
-23; should be 0
I would much rather have something that stops and rases an error
when there is a problem rather then invisably continues to propogate
bad data. I really want to be able to trust my tools.
marc
Marc Spitzer <········@optonline.net> writes:
> I would much rather have something that stops and rases an error when
> there is a problem rather then invisably continues to propogate bad
> data. I really want to be able to trust my tools.
where did you see an error? that was my whole point: there WAS NO
ERROR. So you're either off by (- 1047 1024) => 23 or you're off by
positive infinity. Which do you prefer?
dave
Dave Bakhash <·····@alum.mit.edu> writes:
> Marc Spitzer <········@optonline.net> writes:
>
> > I would much rather have something that stops and rases an error when
> > there is a problem rather then invisably continues to propogate bad
> > data. I really want to be able to trust my tools.
>
> where did you see an error? that was my whole point: there WAS NO
> ERROR. So you're either off by (- 1047 1024) => 23 or you're off by
> positive infinity. Which do you prefer?
>
positive infinity, it is trivial(and somewhat tedious) to check for.
Numbers that are off by about 2%, in your example, are much harder to
catch. They will be more likely to reach production and then cost
/real/ money in losses to business.
I would conceptually consider +inf to be an error, even if it does not
raise one, because I have a numeric type telling me the number is too
big to deal with so you the programmer deal with it.
marc
Marc Spitzer <········@optonline.net> writes:
> > where did you see an error? that was my whole point: there WAS NO
> > ERROR. So you're either off by (- 1047 1024) => 23 or you're off by
> > positive infinity. Which do you prefer?
> >
>
> positive infinity, it is trivial(and somewhat tedious) to check for.
> Numbers that are off by about 2%, in your example, are much harder to
> catch. They will be more likely to reach production and then cost
> /real/ money in losses to business.
You may be true...but remember that the whole point of an application is
that it deals with data dynamically. You may write an application, not
catch the bug, and then ship it. So, imagine that this thing is
controlling someone's pacemaker (talk about an embedded CL! :-)...if
that app somehow comes up with +inf, then you're just toast. If it
comes up with 1047 instead of 1024, then there's a good chance that the
person lives.
The whole point of +inf instead of an error is that it is *not* an
error...Of course, I hate both wrong answers...shoot...I not even that
pleased with 1024.0, since I wanted to see an integer come back.
> I would conceptually consider +inf to be an error, even if it does not
> raise one, because I have a numeric type telling me the number is too
> big to deal with so you the programmer deal with it.
the point is this...on one hand, you have something that's easier to
debug; on the other hand you have something that is guaranteed death.
It's possible to have both, though. The Lisp implementor can easily
signal (i.e. with SIGNAL, and not ERROR) a condition that says that
suddenly parts of the extended real number system (e.g. +/- inf, NaN)
have been issued, and are now part of return values...If you don't have
a handler, they they're just ignored...
If the implementors had such a condition, and exposed it as part of the
behavior, then I'd agree with you, or at least agree with you more.
dave
Dave Bakhash <·····@alum.mit.edu> writes:
> Marc Spitzer <········@optonline.net> writes:
>
> > > where did you see an error? that was my whole point: there WAS NO
> > > ERROR. So you're either off by (- 1047 1024) => 23 or you're off by
> > > positive infinity. Which do you prefer?
> > >
> >
> > positive infinity, it is trivial(and somewhat tedious) to check for.
> > Numbers that are off by about 2%, in your example, are much harder to
> > catch. They will be more likely to reach production and then cost
> > /real/ money in losses to business.
>
> You may be true...but remember that the whole point of an application is
> that it deals with data dynamically. You may write an application, not
> catch the bug, and then ship it. So, imagine that this thing is
> controlling someone's pacemaker (talk about an embedded CL! :-)...if
> that app somehow comes up with +inf, then you're just toast. If it
> comes up with 1047 instead of 1024, then there's a good chance that the
> person lives.
but checking for +inf would show up in testing and be caught(the
numbers just would not make sense. But lets look at a more likely
example, a business app. You report to your boss "hey boss in app
foobar in 3% of all transactions our numbers are off by 2% for the
last 6 months. I think we need to pay out about $50,000,000 to make
it right". On the bright side lisp is being used in a large project,
it will never happen again though. Besides for medical stuff, from
what little I know, testing cost more then development. You test for
/any/ possibility. Remember you can get sued over a faulty pacemaker,
so can the lisp vendor who said its tools can be used in medical
apps. The standard software is too complicated to get right will not
hold water here( as far as I know, I am not a lawyer yada yada)
>
> The whole point of +inf instead of an error is that it is *not* an
> error...Of course, I hate both wrong answers...shoot...I not even that
> pleased with 1024.0, since I wanted to see an integer come back.
>
fair enough
> > I would conceptually consider +inf to be an error, even if it does not
> > raise one, because I have a numeric type telling me the number is too
> > big to deal with so you the programmer deal with it.
>
> the point is this...on one hand, you have something that's easier to
> debug; on the other hand you have something that is guaranteed death.
That is what testing is for and bug reports to vendors.
my real fear in this matter is that you do not find the errors,
because they are so small, and down the line you are really screwed.
>
> It's possible to have both, though. The Lisp implementor can easily
> signal (i.e. with SIGNAL, and not ERROR) a condition that says that
> suddenly parts of the extended real number system (e.g. +/- inf, NaN)
> have been issued, and are now part of return values...If you don't have
> a handler, they they're just ignored...
>
> If the implementors had such a condition, and exposed it as part of the
> behavior, then I'd agree with you, or at least agree with you more.
>
I agree that would be better.
marc
Dave Bakhash wrote:
> Marc Spitzer <········@optonline.net> writes:
>
>>I would much rather have something that stops and rases an error when
>>there is a problem rather then invisably continues to propogate bad
>>data. I really want to be able to trust my tools.
>
> where did you see an error? that was my whole point: there WAS NO
> ERROR. So you're either off by (- 1047 1024) => 23 or you're off by
> positive infinity. Which do you prefer?
I think you're missing the special role that +/- infinity and
not-a-number play in floating point. Once you encounter one of those
values, they will propigate all the way through to the result (in the
absence of a system that uses of exception of course).
To be specific, the floating point operations all have specified results
that are appropriate given an infinite or not-a-number parameter. For
example, multiplying anything infinity results in infinity. Adding
anything except infinity to infinity results in infinity (infinity +
infinity is NaN if the signs don't match, or that signed infinity if
they do).
Some more details:
http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html#specials
Now, as for this business of some Lisp implementations punting on
transcendental functions leaving them to just use floating point, rather
than using nice indefinite precision numbers, I agree that it is indeed
frustrating when you do want those big numbers to work.
Jim
Jim White <···@pagesmiths.com> writes:
> I think you're missing the special role that +/- infinity and
> not-a-number play in floating point. Once you encounter one of those
> values, they will propigate all the way through to the result (in the
> absence of a system that uses of exception of course).
Of course, I know exactly how +/- infinity works, and NaN. What I said
was that indeed you'll see these kinds of answers, but often by the time
you do, you've already paid a serious price.
I think people have been having trouble getting this simple point, so
let me make it explicit:
If I had to choose one or the other for the _rest of time_:
(log (expt 2 1024) 2) => 1047
or
(log (expt 2 1024) 2) => +inf
I'd probably take the first one. I do recognize that it will be much
harder to debug an application that returns the first thing...but
looking purely at the answers themselves, one of these answers has an
error of about 2.25% and the other is infinately off.
from the perspective of debuggability, though, yeah...it's nice to see
an answer which makes it obvious that a calculation somewhere went
wrong.
dave
Dave Bakhash wrote:
> If I had to choose one or the other for the _rest of time_:
>
> (log (expt 2 1024) 2) => 1047
>
> or
>
> (log (expt 2 1024) 2) => +inf
>
> I'd probably take the first one. I do recognize that it will be much
> harder to debug an application that returns the first thing...but
> looking purely at the answers themselves, one of these answers has an
> error of about 2.25% and the other is infinately off.
That is not a very reasonable position. This issue has to do with
having a precise, predictable, and repeatable set of rules for
computation (which IEEE 754 is and why it has been so successful).
I agree that there would be some uses for a system that guaranteed that
the results would always be with 2.25% but never overflow, but that is
obviously not what is being discussed here.
Jim
On Tue, 10 Dec 2002 18:30:12 -0700, Chris Gehlker wrote:
> I tried it on the demo version of Macintosh Common Lisp and, after a long
> delay, I got 1024. So I tried OpenMCL, which immediately returned 1047. This
> is very strange since those two implementations supposedly use the same code
> for math. I started thinking that the commercial version might have it's own
> software FP library that's slower but more accurate than the on-chip FP. So
> I tried Clisp which immediately returned 1024. Now I'm *really* stumped.
I tried it on the real MCL 5.0 beta (not the demo version):
? (time (log (expt 2 1024) 2))
(LOG (EXPT 2 1024) 2) took 0 milliseconds (0.000 seconds) to run.
96 bytes of memory allocated.
1024.0
?
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>
Dave Seaman <·······@no.such.host> writes:
> I tried it on the real MCL 5.0 beta (not the demo version):
>
> ? (time (log (expt 2 1024) 2))
> (LOG (EXPT 2 1024) 2) took 0 milliseconds (0.000 seconds) to run.
> 96 bytes of memory allocated.
> 1024.0
> ?
FWIW, Symbolics Genera also returns 1024.0 for this expression.
>>>>> "Carl" == Carl Shapiro <·············@panix.com> writes:
Carl> Dave Seaman <·······@no.such.host> writes:
>> I tried it on the real MCL 5.0 beta (not the demo version):
>>
>> ? (time (log (expt 2 1024) 2))
>> (LOG (EXPT 2 1024) 2) took 0 milliseconds (0.000 seconds) to run.
>> 96 bytes of memory allocated.
>> 1024.0
>> ?
Carl> FWIW, Symbolics Genera also returns 1024.0 for this expression.
On those systems where the log returns something, what does it return
for (log (expt 2 1024) 3) or (log (expt 3 1024) 2)?
Just curious.
Ray
On 13 Dec 2002 10:25:30 -0500, Raymond Toy wrote:
>>>>>> "Carl" == Carl Shapiro <·············@panix.com> writes:
> Carl> Dave Seaman <·······@no.such.host> writes:
> >> I tried it on the real MCL 5.0 beta (not the demo version):
> >>
> >> ? (time (log (expt 2 1024) 2))
> >> (LOG (EXPT 2 1024) 2) took 0 milliseconds (0.000 seconds) to run.
> >> 96 bytes of memory allocated.
> >> 1024.0
> >> ?
> Carl> FWIW, Symbolics Genera also returns 1024.0 for this expression.
> On those systems where the log returns something, what does it return
> for (log (expt 2 1024) 3) or (log (expt 3 1024) 2)?
Using MCL 5.0 beta:
? (log (expt 2 1024) 3)
646.0720676571724
? (log (expt 3 1024) 2)
1623.001600738464
?
> Just curious.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>
>>>>> "Dave" == Dave Seaman <·······@no.such.host> writes:
Dave> On 13 Dec 2002 10:25:30 -0500, Raymond Toy wrote:
>>>>>>> "Carl" == Carl Shapiro <·············@panix.com> writes:
Carl> Dave Seaman <·······@no.such.host> writes:
>> >> I tried it on the real MCL 5.0 beta (not the demo version):
>> >>
>> >> ? (time (log (expt 2 1024) 2))
>> >> (LOG (EXPT 2 1024) 2) took 0 milliseconds (0.000 seconds) to run.
>> >> 96 bytes of memory allocated.
>> >> 1024.0
>> >> ?
Carl> FWIW, Symbolics Genera also returns 1024.0 for this expression.
>> On those systems where the log returns something, what does it return
>> for (log (expt 2 1024) 3) or (log (expt 3 1024) 2)?
Dave> Using MCL 5.0 beta:
Dave> ? (log (expt 2 1024) 3)
Dave> 646.0720676571724
Dave> ? (log (expt 3 1024) 2)
Dave> 1623.001600738464
Very nice.
How about
(defun foo (x n)
(log x n))
(foo (expt 3 1024) 2)
I'm just trying to reverse engineer what these implementations are
doing. If this example works, they have done a very nice job of
implementing log. It would be a pain (for me, anyway) to do something
like this.
Ray
On 12/13/02 11:44 AM, in article ··············@rtp.ericsson.se, "Raymond
Toy" <···@rtp.ericsson.se> wrote:
>
> How about
>
> (defun foo (x n)
> (log x n))
>
> (foo (expt 3 1024) 2)
>
> I'm just trying to reverse engineer what these implementations are
> doing. If this example works, they have done a very nice job of
> implementing log. It would be a pain (for me, anyway) to do something
> like this.
Welcome to Macintosh Common Lisp Version 5.0!
? (defun foo (x n)
(log x n))
FOO
? (foo (expt 3 1024) 2)
1623.001600738464
?
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
>>>>> "Raymond" == Raymond Toy <···@rtp.ericsson.se> writes:
Raymond> implementing log. It would be a pain (for me, anyway) to
Raymond> do something like this.
I was being stupid. This is actually pretty easy.
(log n b) = (/ (log n 2) (log b 2))
Write n as 2^m*f where 1/2 < f <= 1. Then (log n 2) is
(+ m (log f 2))
Easy.
Ray
Dave Bakhash wrote:
> Hey,
>
> I ran into problems with the LOG function in CL. I was using LispWorks,
> and after realizing that some basic support for bignum arithmatic is
> weak...I'd even call it broken.
>
It's not just LOG. In CMUCL, you can't even multiply (expt 2 1024) by 1.0d0,
because the former is "too large to be represented as a double float".
Oleg
* oleg inconnu wrote:
> It's not just LOG. In CMUCL, you can't even multiply (expt 2 1024) by 1.0d0,
> because the former is "too large to be represented as a double float".
Um. That's a result of the rules of float contagion, and a correct one.
Just for grins, I tried this in Mathematica 4.0, it has pretty good support
for large integers.
Log[2, 2^1024] returns 1024, just like you'd hope.
I thought it was purely symbolic, but found that "Log[2, 2^123456789]" works
fine, but you can blow it up:
Log[2, 2^1234567890]
General::"ovfl": "Overflow occurred in computation."
Alan.
"Dave Bakhash" <·····@alum.mit.edu> wrote in message
····················@nerd-xing.mit.edu...
> Hey,
>
> I ran into problems with the LOG function in CL. I was using LispWorks,
> and after realizing that some basic support for bignum arithmatic is
> weak...I'd even call it broken.
>
> LispWorks:
>
> CL-USER 1 > (log (expt 2 1024) 2)
> +1D++0 #| +1D++0 is double-float plus-infinity |#
>
> ACL:
>
> CL-USER(1): (log (expt 2 1024) 2)
> Error: This integer is too large to be converted to a double-float:
>
179769313486231590772930519078902473361797697894230657273430081157732675\
>
8055009631327084773224075360211201138798713933576587897688144166224928474306
394\
>
7412437776789342486548527630221960124609411945308295208500576883815068234246
288\
>
1473913110540827237163350510684586298239947245938479716304835356329624224137
216
> [condition type: SIMPLE-ERROR]
>
> Restart actions (select using :continue):
> 0: Return to Top Level (an "abort" restart).
> 1: Abort entirely from this process.
> [1] CL-USER(2):
>
> ECL:
>
> > (log (expt 2 1024) 2)
> Not a number.
> Broken at LOG.
> >>
>
> Of the implementations that I tried, only CLISP gets it right:
>
> CLISP:
>
> > (log (expt 2 1024) 2)
> 1024
> >
>
> Some of the above results are embarrassing. Even M-x calc gets it
> right, no problem.
>
> I'd even be happy if this returned 2.0, or even 1.999999 etc.
>
> Lisps should be better than this.
>
> dave