Re: [clisp-list] log and overflow

[Kaz K. <kky...@gm...>]

On Fri, Jan 16, 2009 at 7:05 PM, Don Cohen
<don...@is...> wrote:
> Gabriel Dos Reis writes:
>  > The call to the function log in the form
>  >     (log (expt 234 108) 10)
>  > signals a floating point overflow.
>  > I'm not sure the hyperspec specifies an exceptional
>  > situation in this case.  Both SBCL and GCL evaluates
>  > the form without fuss.
> Just as a guess, the integer (expt ...) is probably being converted to
> float, and this integer is too big to be converted.

Uh, you're using exponentiation to create a large number, which you
then reduce with a logarithm. Algebra calling!

Purely mathematically speaking (not numerically):

  (log (expt base-1 exponent) base-2)

  ==>

  (* exponent (log base-1 base-2))

So:

  (* 108 (log 234 10))  ->  255.87532

> Perhaps the code should check the size and use a larger float format
> if necessary.  I was wondering what type of result should be expected
> here.

Given that the mathematical value is an irrational number close to 255.87532,
I'd say that all bets are off for an integer or rational. :)

By the way, you can check that the result 255 is in the right ball
park by calculating the string length of the decimarl representation
of the big number (since the base for your reducing log is 10).

(length (princ-to-string (expt 234 108))) -> 256

> The hyperspec says log can return either an integer or float in
> cases where the result is actually an integer.

CLISP's log is quite nicely behaved like that. It returns rationals
too: (log 10 100) -> 1/2.