Re: bug in (log)
Hey,
sorry for taking my time with the response. While indeed conforming, I've added
a separate code path for ratios. I'm conditioning on the integer length (like
SBCL does).
static cl_object
ecl_log1_ratio(cl_object x)
{
cl_object num = x->ratio.num;
cl_object den = x->ratio.den;
if (ecl_integer_length(num) != ecl_integer_length(den)) {
return ecl_minus(ecl_log1(num), ecl_log1(den));
} else {
return ecl_log1_fixnum(x);
}
}
Thanks all for the input. The change is now submitted as a merge request
against develop (and will be part of the next release).
Best regards,
Daniel
--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu
"Be the change that you wish to see in the world." - Mahatma Gandhi
--- Original Message ---
On Sunday, July 10th, 2022 at 5:39 PM, James Cloos wrote:
> i should have realized this even before noticing ecl's limitation for
> logs of ratios, but at least i finally did
>
> since i'monly using log to find the exponent for an arbitrary precision
> replacement for format's ~e, it works to truncate first.
>
> so i ended up with this:
>
> (defun ilog (n &optional (base nil base-p))
> "return floor of base b log of n"
> (let ((s (if (< n 1) -1 1))
> (trunc-n (truncate (if (< n 1) (/ n) n
> (floor (* s (if base-p
> (log trunc-n base)
> (log trunc-n))
>
>
> One could use let* and then test s when choosing between n and (/ n), but
> i choose instead to let the compiler optimize the two calls to (< n 1).
>
> that makes my ~e replacement work exactly as desired on all lisps i've tried.
>
> (I have a ~// function which chooses output baed on the arg's type, with
> ratios done via that print-e-significant-digits function and everything
> else using write.)
>
> -JimC
> --
> James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
>
>
Re: bug in (log)
i should have realized this even before noticing ecl's limitation for logs of ratios, but at least i finally did since i'monly using log to find the exponent for an arbitrary precision replacement for format's ~e, it works to truncate first. so i ended up with this: (defun ilog (n &optional (base nil base-p)) "return floor of base b log of n" (let ((s (if (< n 1) -1 1)) (trunc-n (truncate (if (< n 1) (/ n) n (floor (* s (if base-p (log trunc-n base) (log trunc-n)) One could use let* and then test s when choosing between n and (/ n), but i choose instead to let the compiler optimize the two calls to (< n 1). that makes my ~e replacement work exactly as desired on all lisps i've tried. (I have a ~// function which chooses output baed on the arg's type, with ratios done via that print-e-significant-digits function and everything else using write.) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: bug in (log)
On Sun, Jul 3, 2022 at 8:10 AM James Cloos wrote: > it looks like that bug only harms ratio. bignum integer seems to be ok. > > so aworkarount is, in the caseof a ratio, to take the difference of the > logs of the numerator and the denominator. > This is basically what cmucl does. But you have to be careful if the numerator and denominator are very close to each other. Then you'll take the difference of two logs that are essentially equal and lose lots or precision. IIRC, cmucl doesn't do this if the ratio is close to 1 because then converting to double-float isn't a problem. There are other ways to handle this though, like implementing a log2 function that returns the integer part and the fraction separately so you don't lose too many fraction bits when the numbers are huge. > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > -- Ray
Re: bug in (log)
it looks like that bug only harms ratio. bignum integer seems to be ok. so aworkarount is, in the caseof a ratio, to take the difference of the logs of the numerator and the denominator. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: bug in (log)
This is permitted by http://www.lispworks.com/documentation/HyperSpec/Body/12_acc.htm On Sun, Jul 3, 2022 at 12:10 AM James Cloos wrote: > > (gitlab is uusable; i have to report here.) > > ecl 21.2.1 gives: > > > (log 1/6319748715279270675921934218987893281199411530039296) > > Debugger received error of type: DIVISION-BY-ZERO > # > Error flushed. > > whereas other cl's (i testyed sbcl and ccl) give results like: > > ? (log 1/6319748715279270675921934218987893281199411530039296) > -119.27552 > > I tested on amd64 (gentoo) and arm64 (debian and netbsd) with identical > results. i did not have a musl box or other bsd to test on. > > run with --no-trap-fpe, the result is #. > > another example is: > > (truncate (log 1/6319748715279270675921934218987893281199418867)) > > Debugger received error of type: ARITHMETIC-ERROR > # > > whereas this works: > > (truncate (log 1/631974871527927067592193421898789328119941867)) > > -103 > -0.27893066 > > which of course suggests that the issue is c's long double's precision. > > it looks like ecl could use an mpq log function; > https://github.com/linas/anant might work. > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 >
