[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Raymond Toy
Subject: Re: [Gcl-devel] Re: [Maxima] float to bfloat
Date: Fri, 30 Jan 2004 14:43:48 -0500
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (celeriac, usg-unix-v)

>>>>> "Richard" == Richard Fateman <address@hidden> 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.  


reply via email to

[Prev in Thread] Current Thread [Next in Thread]