(j3.2006) IEEE 754 [was re letter ballot on interps]

[N.M. Maclaren]

On Feb 12 2010, Toon Moene wrote:
>
>F03/0078: This answer might come back to haunt us.  People who want to
>           follow IEEE 754 strictly *need* the assurance that the
>           text of the program is followed verbatim, because, although
>           X(I) / A is mathematically equivalent to X(I) * (1/A), it
>           certainly isn't in IEEE 754 arithmetic (compilers do this to
>           turn division by a loop-invariant into a cheaper
>           multiplication).

No, it is the converse answer that would come back to haunt us.  If you
want strictly deterministic floating-point results, then you should be
using a portable assembler.  Oh, and not writing seriously parallel
code, either.  I am not joking :-(

If you want IEEE 754 determinism, then ask yourself which of the
following should X**N generate (in general, they are all different):

    1) The binary reduction code using IEEE 754, which is what almost
every library does, but sometimes inline code doesn't.

    2) The same result as X*X*X*...

    3) The correctly rounded result of X^N.

There is also a similar problem with (parallel) reductions and operation
ordering.  And, there, in general, solution (3) is intractable - but
virtually nobody uses general reductions.

One of the things that was in the original objectives of IEEE 754 was
to tackle the reasons that no programming language had adopted it in
a couple of decades.  There were some reasonable proposals to change it
in the general direction of where programming languages have been since
the 1960s (sic).  But they lost out in committee.

Regards,
Nick Maclaren.