A related problem:
(%i8) sqrt(4*exp(2009));
Maxima encountered a Lisp error:
FLOATING-POINT-OVERFLOW detected
performing EXP on (2009.0)
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
With either SBCL 1.0.29 or Clozure CL, Maxima reports a floating point overflow error computing
the real part of sqrt(4*%e^2009-3)-1. Likely, this is a bug in sign or friends.
(%o20) sqrt(4*%e^2009-3)-1
(%i21) realpart(%);
Maxima encountered a Lisp error:
arithmetic error FLOATING-POINT-OVERFLOW signalled
(%i22) build_info();
Maxima version: 5.19post
Maxima build date: 7:45 10/16/2009
Host type: i686-pc-mingw32
Lisp implementation type: SBCL
Lisp implementation version: 1.0.29
Let's try Clozure:
(%o5) sqrt(4*%e^2009-3)-1
(%i6) realpart(%);
Maxima encountered a Lisp error:
FLOATING-POINT-OVERFLOW detected
performing EXP on (2009.0)
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i7) build_info();
Maxima version: 5.19post
Maxima build date: 5:44 10/17/2009
Host type: i686-pc-mingw32
Lisp implementation type: Clozure Common Lisp
Lisp implementation version: Version 1.4-dev (WindowsX8632)
A related problem:
(%i8) sqrt(4*exp(2009));
Maxima encountered a Lisp error:
FLOATING-POINT-OVERFLOW detected
performing EXP on (2009.0)
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
And another related bug:
(%i13) sign(exp(2009));
Maxima encountered a Lisp error:
FLOATING-POINT-OVERFLOW detected
performing EXP on (2009.0)
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i14) build_info();
Maxima version: 5.19post
Maxima build date: 5:44 10/17/2009
Host type: i686-pc-mingw32
Lisp implementation type: Clozure Common Lisp
Lisp implementation version: Version 1.4-dev (WindowsX8632)
This bug depends on the Lisp. With GCL it is not observable. The reason is the different handling of floating point overflows.
The problem is caused in the routine NUMER in compar.lisp. This routine is called in SIGN1 for constant expressions which can be evaluated numerically. NUMER calls $FLOAT. The Lisp error occurs in EXPTRL.
That is the floating point overflow we get in $FLOAT:
(%i5) float(exp(2009));
Maxima encountered a Lisp error:
COMMON-LISP:EXP: floating point overflow
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
I have tried the following patch to catch the Lisp error in $FLOAT:
(defun numer (x)
(let (($numer t) ;currently, no effect on $float, but proposed to
result)
;; Catch a Lisp error an return NIL
;; if a floating point overflow occurs.
(setq result (let ((errset nil)) (errset ($float x))))
(if result (car result) nil)))
With this patch we get the expected answers for all examples of this bug report:
(%i6) sign(exp(2009));
(%o6) pos
(%i7) realpart(sqrt(4*%e^2009-3)-1);
(%o7) sqrt(4*%e^2009-3)-1
(%i8) sqrt(4*exp(2009));
(%o8) 2*%e^(2009/2)
The testsuite and GCL have no problems with this patch.
Dieter Kaiser
The Lisp error in the function numer in compar.lisp revision 1.61 is catched.
Closing this bug report as fixed.
Dieter Kaiser