Dave Berry writes:

> Are you saying that if (a * b) would result in a NaN
>then you always want (a * b * 0.0) to return a NaN, so that you are aware
> of the potential problem?

Yes! That is indeed the case. This is what the IEEE floating point spec
calls for. There are two kinds of Nan's -- signaling and non-signaling. The
signaling ones can potentially raise an exception, while the non-signaling
ones simply represent "Not-A-Number" values. One might use signaling Nan's
to initialize arrays, in some languages (i.e., Fortran) so that one could
catch the use of uninitialized variables...

I don't really distinguish the two in most of my work... Indeed, on the
Alpha architecture, you have to explicitly check for such errors by
inserting trap barrier instructions into the instruction stream. Hence, all
you can know is whether or not an exception has occured since the last time
you checked. The IEEE floating point spec allows for this kind of behavior
in the readily available FPU architectures as well (i.e., Pentium)

Most of my work involves signal and image processing on vast collections of
numbers, frequently in real-time environments. While the numerical analysts
might like to know about Nan signaling to help them write more sophisticated
(mathematical) function evaluators, nearly all of my math routines have to
be quick and not so exacting. In physics and measurement environments we
rarely have more than 3 significant digits in our data. Of course the work
of Prof. William Kahan, UC Berkeley, shows the need to carry many more
significant digits during intermediate calculations, but mathematical
refinement is not generally our concern. As I mentioned previously, if an
anomalous computation occurs in one or a few cases out of the billions that
we stream then we just drop it (them) on the floor and keep running...

- DM