RISKS note about IEEE-754

[Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>]

Richard Karpinski quoted the following from Henry Baker:

     Whether intended or not, one consequence of the widespread
     implementation of IEEE-754 floating point arithmetic is that
     almost every computer now gets _exactly_ the same answer,
     down to the last little bit.  This "answer" may be far from
     the "correct" answer, but at least all of the computers will
     be consistent.  In the "old" (pre-754) days, running the
     same Fortran program on several different computers could
     uncover potential sources of error.  No longer.

If that was the case we would not need that new Clause 11, now would we?

While I'm quite aware of the risks of monoculture, I don't think
IEEE 754 is one of them.  The most important reason is that IEEE 754
does not simply demand a common answer (where it does), but the
*correct* answer, in a well-defined mathematical sense (NOT that of
real-number arithmetic).  This is *very* different from conformance
requirements like those of early Java, where the results had to match
those of a particular implementation (libm) which was not required to
be correct (only "good enough").  In other words, known incorrect
answers had to be reproduced exactly.

As most of those on this forum know, there are a few places where the
standard allows differences, and where there are in fact different
implementations -- but most of the non-reproducibility of results
across platforms (which is what is being discussed here) are the
result of higher-level effects, most notably compiler licence and
various performance tradeoffs.

As to being able to get a fuzzy feeling of correctness from the
fact that several rather different implementations of the same
algorithm get the same result (to within the supported precision),
please take a look at the Rump polynomial (look it up).  Here we
get the same TOTALLY INCORRECT result when evaluated in Single,
Double and Extended precision -- and that includes running the
same Fortran program on different computers!

I don't disagree with the fact that running the same program with
different precisions and different rounding modes is a powerful
means to detect misbehaving algorithms -- indeed, it is a point
that Prof. Kahan has made quite eloquently a number of times.
I am quite frustrated myself that features that could enable
effective debugging do not receive the support they deserve --
but I am also painfully aware of the difficulty of architecting
such features in a way that many diverse organisations (even
within one company) could agree on -- that would be believed to
not affect performance in the common case, and that could find
a sponsor willing to bear the development and testing costs.

Michel.
Sent: 2007-10-18 22:27:00 UTC