Jan Bottorff wrote:
> 
> Squeak seems to rairly test for NaN's before or after an operation.

This is not too strange. Most operations return a NaN if given a NaN.

> My understanding of alternative floating point error modes is: you can
> get a processor exception when certain errors occur (much like integer
> division by 0), or you tell the processor not to fault, but to return
> a distinguishing value (NaN) when an error occurs.

Actually it is a bit more complicated on x86 processors. If it's integer
arithmetic in the normal registers, a processor exception will be thrown
(which, I assume, is caught by the VM and converted into the "right
thing" inside Squeak). If it's done in a floating-point registers, a NaN
will be the result; it will also throw an exception if a certain
floating-point mode is in effect (actually there are certain FP modes,
for error signalling, rounding mode, and one or two other things).

Another interesting point is that there are different NaNs:
* positive infinity
* negative infinity
* indefinite (like square root of a negative number)
* User-defined NaNs (useful for explicitly propagating error information
through operations)

> It offhand seems like the right thing for a floating point primitive
> to do when passed a NaN value would be to fail the primitive. Also
> mabey when a floating point primitive is going to return a NaN, it
> should also fail. I looked at the VM, and currently, NaN's are pretty
> much just passed thru and returned, like nothing is wrong.

This is as it should be IMHO. If a NaN is passed in it should also go
out (usually; dividing a nonzero number by an infinity could justifiably
return zero). The program can still check for the NaN at the end of the
calculation. However, reacting to an error is the domain of the
top-level routine, so you won't see many checks for NaNs in library
code.

Regards,
Joachim
-- 
Please don't send unsolicited ads.