>>>>> "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
