Re: bug in (log)
Jeronimo Pellegrini <[email protected]> Sun, 03 Jul 2022 10:57:52 -0300
| Newsgroups | gmane.lisp.ecl.general |
|---|---|
| Message-ID | <[email protected]> |
Out of curiosity -- the spec mentions "floating point approximations", and in this case I understand it is reasonable (a very small number is treated like zero). But is floating-point infinity also considered an approximation to very large numbers? (setq x (expt 10 5000)) (log x) => 11512.926 ECL, SBCL, Clisp, CCL, CMUCL return 11512.926. ABCL doesn't (it actually invokes a TYPE-ERROR condition, because the number is too large to be converted to DOUBLE-FLOAT) -- but it does not return float infinity. GCL's behavior is a bit more complicated: (setq x (expt 10 5000)) (progn (setq y (log x)) 'whatever) ;; don't let GCL print it yet! => WHATEVER (type-of y) => LONG-FLOAT But If I ask for the value of y on the REPL: Error: Fast links are on: do (si::use-fast-links nil) for debugging Signalled by SYSTEM::GCL-TOP-LEVEL. Condition in SYSTEM::GCL-TOP-LEVEL [or a callee]: INTERNAL-SIMPLE-ERROR: Can't print a non-number. (So I produced a non-printable LONG-FLOAT object by just calling `log` on an integer.) I did not test Clasp. Anyway - I was just wondering how to interpret the standard in this respect. J. Stas Boukarev <[email protected]> writes: > 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 <cloos-GRsvFm/Gh/[email protected]> 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 >> #<a DIVISION-BY-ZERO 0x7ff5afe6c540> >> 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 #<single-float negative infinity>. >> >> another example is: >> >> (truncate (log 1/6319748715279270675921934218987893281199418867)) >> >> Debugger received error of type: ARITHMETIC-ERROR >> #<a ARITHMETIC-ERROR 0xffff8f688a40> >> >> 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 <cloos-GRsvFm/Gh/[email protected]> OpenPGP: 0x997A9F17ED7DAEA6 >>