Re: [Gcl-devel] Re: [Maxima] float to bfloat

[Raymond Toy]

>>>>> "Steve" == Steve Haflich <address@hidden> writes:

    Ray> But this seems so implementation specific that using a
    Ray> standard CL function to get at it is non-portable at best.
    Ray> But I also have a vague memory that if you catch an overflow
    Ray> error, the fraction and exponent contain the right answer,
    Ray> except that exponent is off by some fixed, known amount.  You
    Ray> lose that if you all overflows get converted to infinity.
    Ray> But I don't know if any hardware actually does that.

    Steve> I'm not familiar with any system that does this.  In particular, a
    Steve> floating infinity always has a zero frational part.

I think it was in one of Kahan's papers.  But it was talking about the
FPU signaling an overflow.  The register would have useful
information.  If you don't signal the overflow, then you'd get a
infinity, which doesn't have room for anything else, as you say.

    Ray>    So as long as scale-float with the output of integer-decode-float
    Ray>    produces the original infinity or NaN, then I guess everything is 
ok,
    Ray>    and no error is an acceptable solution.  

    Steve> I think this is unwise.  The results of integer-decode-float are not
    Steve> merely magic quantities with which the float could be reconstructed.
    Steve> The values have a specific mathematical value upon which portable 
code
    Steve> could depend in quite unexpected ways.  IMO it would be better to
    Steve> signal error on i-d-f of an exceptional float.

Like you, I rather like integer-decode-float signaling an error, but I
didn't see anything really wrong with it.  But then you'd need some
other way of determining if the output of i-d-f represented infinity
or NaN.  I like cmucl providing float-infinity-p and float-nan-p, if
that is really necessary or just handling the error from i-d-f.

Ray