(j3.2006) [Fwd: [Wg25-full] Fwd: [Numeric-interest] reproducible floating-point results and 754R]

[Bill Long]

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.
>
>Van
>
>
>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
>committee
>is currently debating the issue of whether reproducible results should
>be
>available to programmers who want them (and are willing to pay
>whatever
>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
>control.
>

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
>programs 
> that produce identical results on all conforming systems.
>
>There is some sentiment that this language should be removed, although
>it
>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 
not unexpected.

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 
Intel ABI. 

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. 


Cheers,
Bill

>
>
>
>I have written some arguments in favor of requiring conforming 
>implementations to provide means to obtain reproducible results at
>
> http://754r.ucbtest.org/msc-ballots/repro.html
>
>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
>
> http://754r.ucbtest.org/msc-ballots/ballot3.html
>
>and encompasses other issues beyond reproducibility.
>
>_______________________________________________
>Numeric-interest mailing list
>Numeric-interest at ucbtest.org
>http://mailman.oakapple.net/mailman/listinfo/numeric-interest
>_______________________________________________
>Wg25-full mailing list
>Wg25-full at lists.nsc.liu.se
>http://www.nsc.liu.se/mailman/listinfo/wg25-full
>
>_______________________________________________
>J3 mailing list
>J3 at j3-fortran.org
>http://j3-fortran.org/mailman/listinfo/j3
>  
>

-- 
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