(j3.2006) F03/0084, was Re: Interp letter ballot #25

Van Snyder Van.Snyder
Fri May 11 16:03:23 EDT 2012

On Fri, 2012-05-11 at 16:52 +0900, Malcolm Cohen wrote:
> Van Snyder wrote:
> >---  -N-  F03/0084   IEEE_SET_ROUNDING_MODE in a subroutine
> >            One of the reasons given for not needing to add interval

---------------^^^ ONE OF THE REASONS!!!

> >            arithmetic to the work plan for 2003
> >            was that the effect
> >            could be provided using the IEEE facilities.
> That was not the reason it lost support.  Even after it lost support, there was 
> still a subgroup tasked with providing "enabling facilities" for it.

If you read my comment carefully, you will see that it says "ONE OF THE
REASONS!"  IEEE support for directed roundings was just one of the nails
in the coffin.

> Grumbles that that subgroup did not do a very good job might well be
> reasonable, but have little to do with this interp.

It is true that if this interp stands, there still will be a multitude
of reasons for not having done interval arithmetic, one being that
nobody who advocated for it actually did any of the necessary work.  But
saying "We don't need A because we have B," and then later saying "Ha!
Ha! Fooled you! We don't really have B" is a bit disingenuous -- no
matter what A and B are.

> (2) Not inhibiting efficient execution on existing and possible future IEEE and 
> IEEE-like hardware was an explicit goal of the IEEE module facilities.  Allowing 
> compilers to continue to use existing optimisations was seen as highly 
> desirable.  There is a wide class of computing devices for which Fortran 
> performance would be severely negatively impacted if exact reproducible results 
> across all machines were to be required by the Fortran standard - this precise 
> effect has already been seen with the Java debacle (they have since relaxed 
> their reproducibility requirements, at least in some circumstances).

This is exactly why Ada has a "strict" mode, and the reason I advocated
for a "strict" mode in Fortran, bounded by a construct or procedure, not
an entire program, during development of the requirements for Fortran
2008.  See 04-218.

It is correct that there is a class of processors for which respecting
the rounding mode is expensive, but this was known when TR 15580 was
accepted.  I don't remember any controversy concerning this issue at
that time.  There are ways processors can reduce this problem.  In any
case, the fraction of deployed processors that are members of this class
has been dwindling for decades.

> (3) This interp contains no edits - the answer is based solely on the text of 
> the standard.  Rescinding the permission for the processor to evaluate a 
> mathematically equivalent expression has never been part of the IEEE TR, 
> subsequent Fortran standards, or the expressed intention of the committee.

If "mathematically equivalent" includes "ignore IEEE rounding mode
changes" then we might as well remove the rounding mode facilities from
the IEEE modules, since the result of this interpretation is "they don't
actually work anyway."

> (4) Even though the standard does not say it completely explicitly, in practice 
> making everything VOLATILE will almost certainly get you your desired outcome....

VOLATILE was not part of the standard when TR 15580 was developed,
passed, or incorporated into Fortran 2003.  It's clear that using
VOLATILE was not contemplated as a means to make IEEE features work.
The intent at the time of TR 15580, and when it was incorporated into
Fortran 2003, was that the facilities it described would work, using the
facilities provided in Fortran 95.

> (5) Finally, although to a fair extent I share your lack of satisfaction with 
> the current situation, I don't think that it is appropriate to change it via 
> interp....

There is no new change or new feature in play here.  The essence of the
interpretation is that there is a contradiction, which needs to be
resolved, between the IEEE rounding features, and permission to use
mathematically equivalent transformations.  The answer to this
interpretation request need not be "mathematically equivalent wins."  It
can just as reasonably be "The IEEE rounding features are intended to
work.  The set of mathematically equivalent transformations does not
include those that violate the rounding mode in effect.  No edits are
necessary."  Indeed, during development of Fortran 2003, there were
arguments that the "mathematically equivalent" permission did not extend
beyond a single expression. draws a distinction between a mathematical difference and a
computational difference.  Upward rounding of a default real expression,
say <expr>, can be written

  real(dble(<expr>) + 0.5*epsilon(1.0e0)*abs(<expr>))

which is, after all, what the processor does when upward rounding is
selected.  Replacing the second term with something not mathematically
equivalent, say 0.0, or -0.5*epsilon(1.0e0)*abs(<expr>), or an arbitrary
choice at the whim of the processor, is not a mathematically equivalent
transformation. continues with the caveat "provided that the integrity of
parentheses is not violated."  So if the example in 0084 had been

             Z1 = (X * Y)
             Z2 = (X * Y)
             PRINT *, 'RESIDUAL: ', Z1 - Z2

would a processor still always be allowed to print zero?

More information about the J3 mailing list