[Top][All Lists]

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

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

From: Richard Fateman
Subject: Re: [Gcl-devel] Re: [Maxima] float to bfloat
Date: Fri, 30 Jan 2004 14:47:18 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

Since there should be a program to decode even an exceptional result,
I would then need to have another program,

As far as encoding the program counter, this is not generally possible
with a 32-bit NaN, but would be likely for a 64-bit NaN and a 32-bit
address space.  Even so, it might not be what you want, which is
why I suggested a pointer into a hash-table where important properties
of the exceptional result could be noted. Like PC, operands, phase of
the moon.   If that table fills up, say with more than 2^24 exceptional
results, then I think you may want to take stock of what you've done
and try something else.

Yes the specifics of the encoding of PC etc is not portable, nor is
it likely that the patching of the hardware interrupt routines would
be identical on various platforms, but the idea of using a hash table
should work.

Steve Haflich wrote:

  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:

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.

Maxima mailing list

reply via email to

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