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.
_______________________________________________
Maxima mailing list
address@hidden
http://www.math.utexas.edu/mailman/listinfo/maxima