gcl-devel
[Top][All Lists]
Advanced

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

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


From: Steve Haflich
Subject: Re: [Gcl-devel] Re: [Maxima] float to bfloat
Date: Fri, 30 Jan 2004 12:12:48 -0800

   To: Richard Fateman <address@hidden>
   
       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.

I'm suspicious about this.  It may have been possible in the days of
teensy-weensy machines like the Dec 20, but on modern platforms there
is insufficient space in a 32-bit NaN to contain a PC or a lisp-object
pointer.  On a 64-bit platform there is not even enough space in a
64-bit NaN.  Also, lisp objects and even code (on some platforms) are
moved by the gc.  I don't think you want the gc reaching inside your
NaN numbers to update their pointers...

   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.

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

I also find suspect the proposal to use symbols to represent NaNs and
Infinities.  The exceptional IEEE floats have a representation like
any other float (whether boxed or unboxed) and there may be many
hidden places in the implementation where code depends on the type of
a float object, even if it doesn't care about the value.  The whole
point of the IEEE inclusion of these exceptional values is that the
hardware can be allowed to generate and further process these,
mathematically-plausible results are maintained.  The reason for doing
this, of course, is so speed senditive fp calculation can depend on
the hardware, rather than having to insert expensive software checks
"Is this value a zero?" or "Did the last operation overflow?"  On many
platforms the FPU is fast but gets hamstrung when it needs to
communicate with the regular cpu logic flow.

For a nice brief (but nonrigorous) overview of IEEE FP representations
and operations, see:
http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html

Note especially the "Special Operations" section which delineates what
happens to these exceptional values under further calculation.
   
   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.  

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




reply via email to

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