Re: [Sbcl-help] type of SB-EXT infinities

 Re: [Sbcl-help] type of SB-EXT infinities From: Paul Khuong - 2012-04-17 16:27:43 ```In article <87vckybed4.fsf@...>, Tamas K Papp 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 ```

 [Sbcl-help] type of SB-EXT infinities From: Tamas K Papp - 2012-04-17 14:52:28 ```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. This makes harmless-looking code like (typecase f (float (decode-float f))) 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. (The issue came up because I am working on a compatibility library that would allow portable treatment if infinities.) Best, Tamas ```
 Re: [Sbcl-help] type of SB-EXT infinities From: Paul Khuong - 2012-04-17 16:27:43 ```In article <87vckybed4.fsf@...>, Tamas K Papp 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 ```