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

[Malcolm Cohen]

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

Bill Long said:
> 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.  

Why?

It seems plausible that setting the optimisation level to zero would
come pretty close (probably close enough) to the stated rules.  Most
of the time users only get ticked off about wrong answers in certain
sensitive parts of their program.

(BTW, many of the "flaws" identified in the Goldberg addendum have
already been addressed by 754r.)

> The number of Fortran programmers willing to pay the performance penalty 
> is, from what I see, essentially zero.

Given the constant level of complaints about strange results, I don't
think that it is a set or measure zero at all.  You later comment about
how (x86) users "would not tolerate" the dodgy x87-based answers; that
rather demonstrates the point.

I agree that the number who would be willing to run their whole program
with no optimisation is close to zero, but I don't think that's what we
are talking about or that that is what 754r is proposing.

Whether what they're proposing is a good idea is another matter;
personally I think the whole revision has become too complicated and
includes too much that is too costly - though since the process is not
public any more, it's a bit hard to tell exactly what is in and what is
out.

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

Nope.  754r is aimed at high-level language programming.

> I can buy that.

However, it's not what they are selling.

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

You and he and I might well agree on this matter, but as Michael pointed
out the ballot results are overwhelmingly positive.  I think it is
inevitably going to become a standard, however flawed it is.  To the
extent it affects the hardware we will be forced to address it.  To the
extent that it affects our users (who will doubtless wish to access its
features at some point), ignoring it is unlikely to be a realistic
option for the long run or even in the medium term.

Cheers,
-- 
........................Malcolm Cohen (malcolm at nag-j.co.jp), Nihon NAG, Tokyo.