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

[Van Snyder]

On Fri, 2007-05-18 at 15:58 -0500, Bill Long wrote:
> 
> 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 way Ada handled this was to provide a block in which a "strict
arithmetic" pragma has effect.  Users realize that the "strict
arithmetic" pragma might turn off optimization.

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