Since there should be a program to decode even an exceptional result,
I would then need to have another program,
integer-decode-float-exceptional-result.
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 <fateman@cs.berkeley.edu>
>
> 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.
>
>_______________________________________________
>Maxima mailing list
>Maxima@www.math.utexas.edu
>http://www.math.utexas.edu/mailman/listinfo/maxima
>
>