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 stassats@gmail.com 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@jhcloos.com 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@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6