(j3.2006) [Fwd: [Wg25-full] Fwd: [Numeric-interest] reproducible floating-point results and 754R]
Fri May 18 16:58:15 EDT 2007
Van Snyder wrote:
>The following is from Bo Einarsson. It was sent to the IFIP WG 2.5
>mailing list. It may be of interest to you.
>From: David Hough 754R work <754r at ucbtest.org>
>To: numeric-interest at ucbtest.org
>Date: Thu, 17 May 2007 13:10:50 -0700 (PDT)
>For those who have not been following 754R's progress, it's currently
>in the sponsor ballot and review phase. The ballot review
>is currently debating the issue of whether reproducible results should
>available to programmers who want them (and are willing to pay
>performance price is required).
There would be two prices - the user sees bad performance, and the
vendor has to spend xxx man-years rewriting the guts of the optimizer to
conform to a specified (by whom?) set of rules on order of evaluation.
The number of Fortran programmers willing to pay the performance penalty
is, from what I see, essentially zero. If the want bad performance,
there are lots of options other than Fortran. The number of corporate
bean counters willing to fund a rewrite of the compiler to appeal to a
group of zero size is also zero.
>The current draft of 754R is expresses its aims this way:
> For operations specified in the normative part of this standard,
> numerical results and exceptions are uniquely determined by the
>values of the
> input data, the operation, and the destination, all under user
This basically says that if the hardware is conforming and the user
writes in assembly language (where the operations are "under user
control") then the answers are predictable. I can buy that.
> Together with language controls it should be possible to write
> that produce identical results on all conforming systems.
>There is some sentiment that this language should be removed, although
>was part of the 754R working group's charter from the IEEE.
As long as the text says "should be possible" is really requires
nothing. Thus it is harmless (and can be left in), but is also useless
(and should be removed). Given this committee's proven inability to
make a decision on even the basic point of the revision, this wording is
If, as is suggested in one of the referenced html files, the "should" is
changed to "shall" then the sentence is unacceptable. The "identical
results" desired are too context dependent. In most cases that I see,
the definition of the "correct" result is whatever the IBM
compiler-generated executable, with that particular user's choice of
optimizations, produces on an SPx system. If a vendor changes their
compiler to conform, then the results are different from those of their
own previous compiler version, irking a different set of users. This
is an issue for negotiation between the vendors and customers, not the
language standard. You can see some effects of this already. For
example, the use of the 80-bit floating point registers on Intel/AMD
chips is essentially dead on modern systems - the new ABI rules it out -
because they are not conforming to the 64-bit IEEE standard. As far as
I can see, this was entirely because users would not tolerate the
"wrong" (see above definition of "correct") answers produced by the old
In the second of the html files, that author pointed out a long list of
reasons why 754r should be disapproved. Given that the committee could
not even decide on a decimal format (one of the issues noted in the
file), I agree with him that disapproval is the best option.
>I have written some arguments in favor of requiring conforming
>implementations to provide means to obtain reproducible results at
>I welcome comments from language designers and mathematical software
>programmers. They could also be sent to Bob Davis, bob at scsi.com,
>chair of the IEEE MSC which chartered 754R.
>My other commentary on 754R ballot reviews is at
>and encompasses other issues beyond reproducibility.
>Numeric-interest mailing list
>Numeric-interest at ucbtest.org
>Wg25-full mailing list
>Wg25-full at lists.nsc.liu.se
>J3 mailing list
>J3 at j3-fortran.org
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3