>>>>> "Richard" == Richard Fateman <fateman@cs.berkeley.edu> writes:
Richard> Raymond Toy wrote:
>>
>>
>> I don't think I would want my Lisp to be able to integer-decode-float
>> a double-float positive infinity, assuming that that is what (expt
>> 9.9d0 9999) has returned.
Richard> I disagree:
Richard> That means any almost user of integer-decode-float must
Richard> guard the call by a check to see if the argument is inf
Richard> or nan, and in case it IS an nan, with no way to decode
Richard> its fraction, which may in in fact have valuable
Richard> information. e.g. the program counter when it was
Richard> produced, or a pointer into a hash-table of a diagnostic
Richard> message, etc. So if integer-decode-float does not
Richard> decompose a NaN into pieces, someone intent on using NaNs
Richard> would have to write a program exactly like
Richard> integer-decode-float. (I've gone this route, actually..)
Yes, you are right. I had forgotten that additional information could
be encoded in a NaN. But this seems so implementation specific that
using a standard CL function to get at it is non-portable at best.
But I also have a vague memory that if you catch an overflow error,
the fraction and exponent contain the right answer, except that
exponent is off by some fixed, known amount. You lose that if you all
overflows get converted to infinity. But I don't know if any hardware
actually does that.
So as long as scale-float with the output of integer-decode-float
produces the original infinity or NaN, then I guess everything is ok,
and no error is an acceptable solution.
Ray