In article <87vckybed4.fsf@...>, Tamas K Papp <tkpapp@...>
wrote:
> Sorry if this is a stupid question, but why is
>
> (typep sbext:doublefloatpositiveinfinity 'doublefloat)
>
> true?
>
> DOUBLEFLOAT 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^ep, 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 floatingpoint 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 floatingpointoverflow or floatingpointunderflow
should be signaled if a floatingpoint 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 (decodefloat f)))
I'd insert a portable check, e.g. (and (/= x 0) (= x (+ x x))). If an
implementation both supports nonfinitefloats and misoptimises that
form, a bug report would be in order (:
Paul Khuong
