In article <87vckybed4.fsf@...>, Tamas K Papp <tkpapp@...>
wrote:
> Sorry if this is a stupid question, but why is
>
> (typep sb-ext:double-float-positive-infinity 'double-float)
>
> true?
>
> DOUBLE-FLOAT is a subtype of FLOAT, and the spec says that
>
> "A float is a mathematical rational (but not a Common Lisp rational)
> of the form s*f*b^e-p, where s is +1 or -1, the sign"
>
> Clearly infinity isn't.
[...]
> when f is an IEEE infinity. Don't get me wrong, I am happy that SBCL
> has IEEE infinities, but if I read the standard correctly they can't be
> a subtype of float.
12.1.4.4 Rule of Float Precision Contagion
The result of a numerical function is a float of the largest format
among all the floating-point arguments to the function.
What's the type of the value of (+ inf 1.0), if infinities aren't floats?
I don't think CL was specified with NaNs or infinities in mind:
12.1.4.3 Rule of Float Underflow and Overflow
An error of type floating-point-overflow or floating-point-underflow
should be signaled if a floating-point computation causes exponent
overflow or underflow, respectively.
That's what SBCL does by default (except on darwin, where FP trap mask
support is slightly broken).
> (The issue came up because I am working on a compatibility library that
> would allow portable treatment if infinities.)
[...]
> (typecase f
> (float (decode-float f)))
I'd insert a portable check, e.g. (and (/= x 0) (= x (+ x x))). If an
implementation both supports non-finite-floats and mis-optimises that
form, a bug report would be in order (:
Paul Khuong
|