(reported by Ariel Badichi on sbcl-devel 2007-01-09)
407a: In sbcl-1.0.1 on Linux x86,
(defun foo ()
(loop for n from (expt 2 1024) do
(handler-case
(coerce n 'single-float)
(simple-type-error ()
(format t "Got here.~%")
(return-from foo)))))
(foo)
causes an infinite loop, where handling the error would be expected.
407b: In sbcl-1.0.1 on Linux x86,
(defun bar ()
(loop for n from (expt 2 1024) do
(handler-case
(format t "~E~%" (coerce n 'single-float))
(simple-type-error ()
(format t "Got here.~%")
(return-from bar)))))
fails to compile, with
Too large to be represented as a SINGLE-FLOAT: ...
from
0: ((LABELS SB-BIGNUM::CHECK-EXPONENT) ...)
1: ((LABELS SB-BIGNUM::FLOAT-FROM-BITS) ...)
2: (SB-KERNEL:%SINGLE-FLOAT ...)
3: (SB-C::BOUND-FUNC ...)
4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
These are now fixed, but (COERCE HUGE 'SINGLE-FLOAT) still signals a
type-error at runtime. The question is, should it instead signal a
floating-point overflow, or return an infinity?
See also bug #309070.
Regarding the question from the bug description, (COERCE HUGE 'SINGLE-FLOAT) should not signal about the overflow. In COERCE description in CLHS, we can read the following:
"If the result-type is any of float, short-float, single-float, double-float, long-float, and the object is a real, then the result is a float of type result-type which is equal in sign and magnitude to the object to whatever degree of representational precision is permitted by that float representation."
This paragraph has nothing about the overflow errors.
Other implementations (CLISP, Clozure) signal the overflow, or return the single-float plus-infinity (Lispworks). I guess that it is right to return the single-float infinity with the correct sign, just because this is formally in accordance with CLHS. Signaling an error is likely to be too severe - it cannot be based on COERCE description in CLHS. Obviously, I can be wrong - this is just my own point of view regarding this problem.