From: Andreas F. <as...@bo...> - 2004-07-19 19:46:35
|
Hi, (scale-float 1.0 most-positive-fixnum) (as used in the test suite) doesn't raise FLOATING-POINT-OVERFLOW any more in 0.8.12.37 on freebsd; 0.8.12.30 does raise the error on the same machine. Sample transcript from 0.8.12.37: CL-USER(10): (scale-float 1.0 most-positive-fixnum) #.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY contrast with 0.8.12.30: CL-USER(2): (scale-float 1.0 most-positive-fixnum) debugger invoked on a FLOATING-POINT-OVERFLOW in thread 87635: arithmetic error FLOATING-POINT-OVERFLOW signalled Operation was SCALE-FLOAT, operands (1.0 536870911). restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). 1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. (SB-KERNEL::SCALE-FLOAT-MAYBE-OVERFLOW 2 1.0 536870911)[:EXTERNAL] 0] -- Andreas Fuchs, <as...@bo...>, as...@ja..., antifuchs |
From: Christophe R. <cs...@ca...> - 2004-07-19 20:58:09
|
Andreas Fuchs <as...@bo...> writes: > Sample transcript from 0.8.12.37: > > CL-USER(10): (scale-float 1.0 most-positive-fixnum) ^^ > #.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY > > contrast with 0.8.12.30: > CL-USER(2): (scale-float 1.0 most-positive-fixnum) ^ > debugger invoked on a FLOATING-POINT-OVERFLOW in thread 87635: > arithmetic error FLOATING-POINT-OVERFLOW signalled > Operation was SCALE-FLOAT, operands (1.0 536870911). I'm betting the floating point modes are incorrectly being reset after taking the ABORT or TOPLEVEL restarts from the debugger. What happens on the second overflowing call to scale-float? Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Andreas F. <as...@bo...> - 2004-07-20 19:30:38
|
On 2004-07-19, Christophe Rhodes <cs...@ca...> wrote: > Andreas Fuchs <as...@bo...> writes: >> debugger invoked on a FLOATING-POINT-OVERFLOW in thread 87635: >> arithmetic error FLOATING-POINT-OVERFLOW signalled >> Operation was SCALE-FLOAT, operands (1.0 536870911). > > I'm betting the floating point modes are incorrectly being reset > after taking the ABORT or TOPLEVEL restarts from the debugger. What > happens on the second overflowing call to scale-float? Further calls to scale-float do the same as the first one; You were close, though. Both forms work correctly in a fresh SBCL image. It only fails to load when float.pure.lisp is loaded; I found these three forms to cause the problems I described above (of which the last two are the more interesting): (defmacro raises-error? (form &optional (error-subtype-spec 'error)) `(typep (nth-value 1 (ignore-errors ,form)) ',error-subtype-spec)) (ignore-errors (funcall (fdefinition 'float-radix) "notfloat")) (assert (raises-error? (scale-float 1.0 most-positive-fixnum) floating-point-overflow)) ;;;; another interesting thing is that (float-radix "notfloat") will not be sufficient to trigger the bug; you have to funcall the fdefinition or the symbol 'float-radix, otherwise it appears to work correctly (and scale-float raises the error). Hm, -- Andreas Fuchs, <as...@bo...>, as...@ja..., antifuchs |
From: Andreas F. <as...@bo...> - 2004-07-20 20:11:06
|
Today, Andreas Fuchs <as...@bo...> wrote: > (ignore-errors (funcall (fdefinition 'float-radix) "notfloat")) > > (assert (raises-error? (scale-float 1.0 most-positive-fixnum) > floating-point-overflow)) > > ;;;; > > another interesting thing is that (float-radix "notfloat") will not > be sufficient to trigger the bug; you have to funcall the > fdefinition or the symbol 'float-radix, otherwise it appears to work > correctly (and scale-float raises the error). Argh, that paragraph is wrong. I must have been testing with an unsaved file. Sorry for the disinformation. -- Andreas Fuchs, <as...@bo...>, as...@ja..., antifuchs |