From: Raymond Toy <toy@rt...>  20020128 14:48:04

>>>>> "Daniel" == Daniel Barlow <dan@...> writes: Daniel> I've done a bit more prodding at it myself and realised that the exact same Daniel> problem can be made to happen on x86 if underflow traps are enabled: Daniel> * (sbint:setfloatingpointmodes :traps '(:overflow :underflow :invalid :dividebyzero)) Daniel> * (sbint:getfloatingpointmodes) Daniel> (:TRAPS (:UNDERFLOW :OVERFLOW :INVALID :DIVIDEBYZERO) :ROUNDINGMODE :NEAREST Daniel> :CURRENTEXCEPTIONS (:INEXACT) :ACCRUEDEXCEPTIONS (:INEXACT) :FASTMODE NIL) Daniel> * (expt 2.0 127) Daniel> debugger invoked on condition of type SBKERNEL:FLOATINGPOINTEXCEPTION: Daniel> [etc] What does the backtrace say? On my CMUCL x86, the back trace shows that unix:write in there, but no expt. (Last time I saw this, there was a missing fwait somewhere.) >> Actually, if it's correct that 1.17549434e38 this is really the least >> positive normalized IEEE single float, then exactly half of that (i.e. >> (EXPT 2.0 127), apparently) seems like a funny value to be constructing. >> Is it possible that you want (EXPT 2.0 126)? leastpositivenormalizedsinglefloat is (expt 2.0 126) on sparc, and my Sparc manual says the same. Daniel> Well, we're calculating LEASTPOSITIVESINGLEFLOAT, so we can Daniel> probably expect the final answer to be denormalized. I think it's Daniel> going to be tricky to get to that answer using only normal floats. Yes. On sparc, this is (expt 2.0 149), and I think this is right since the smallest exponent is 126 and fraction part should be 2^(23) for this denormalized number. Daniel> Maybe disabling underflow traps is the right answer, not Daniel> just the workaround. Do you mean during the calculation or in general? Doesn't SBCL create these values just by smashing the appropriate bits into a single float? If that's true, how does that help? Ray 