#1798 realpart --> floating-point-overflow

closed
nobody
None
5
2009-10-31
2009-10-17
No

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)

Discussion

  • Barton Willis

    Barton Willis - 2009-10-17

    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.

     
  • Barton Willis

    Barton Willis - 2009-10-17

    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)

     
  • Dieter Kaiser

    Dieter Kaiser - 2009-10-31

    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

     
  • Dieter Kaiser

    Dieter Kaiser - 2009-10-31
    • status: open --> closed
     
  • Dieter Kaiser

    Dieter Kaiser - 2009-10-31

    The Lisp error in the function numer in compar.lisp revision 1.61 is catched.
    Closing this bug report as fixed.

    Dieter Kaiser

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks