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

Malcolm Cohen malcolm
Sun May 13 23:16:09 EDT 2012


>On Fri, 2012-05-11 at 16:52 +0900, Malcolm Cohen wrote:
>> 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!"

It's not worth blethering about interval arithmetic all over again anyway, but 
if you read my comment, you would have noticed that I did not agree with you.

>  IEEE support for directed roundings was just one of the nails
>in the coffin.

IMO not even the rust on the top of one of the nails.  Not exactly a "coffin" 
anyway, since WG5 asked for "enabling features" to be added.  Which we didn't 
do.  WE ALL KNEW THAT WE DIDN'T DO IT.  Well, those of us paying attention, 
anyway (I've heard several people grumble specifically about that, and I could 
have sworn you were one of them too).

>It is true that if this interp stands,

Rephrased "It is true that unless we make sweeping changes to the Fortran 
standard to remove optimisability..."

This interp does nothing to inhibit interval arithmetic or otherwise.  There are 
NO EDITS.

...
>This is exactly why Ada has a "strict" mode, and the reason I advocated
>for a "strict" mode in Fortran,

Irrelevant to the question at hand.

>It is correct that there is a class of processors for which respecting
>the rounding mode is expensive,

Yes, and this is a growing percentage.  The only widely-used processor I am 
aware of on which it was not expensive was the DEC Alpha.  Note "was".  It is 
expensive on every commodity processor I have seen since.  There are a number of 
non-commodity specialistic processors that don't have a global rounding mode at 
all, really this is the only case where it is cheap (i.e. when it is encoded 
into each instruction).

>If "mathematically equivalent" includes "ignore IEEE rounding mode
>changes"

No it does not.

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

They do work, they apply to the actual operations being executed.

Note that the rounding mode is inherited, so IEEE_SET_ROUNDING_MODE is 
frequently not visible.  That means that any optimisation-disabling effect that 
you apparently want it to have would potentially need to be applied to the 
entire program.

>It's clear that using
>VOLATILE was not contemplated as a means to make IEEE features work.

Correct, and it is not needed either.

My comment was simply showing one way of disabling unwanted optimisations, a way 
that works fairly locally.  Numerical analysts have been blocking unwanted 
optimisations via other ways for decades, this is not a new problem in any way 
nor does it have any necessary connection to IEEE rounding.  A single assignment 
to and reading from a VOLATILE variable is often cheaper than a whole external 
procedure invocation (the more traditional way of road-blocking the optimiser).

No good deed goes unpunished.  Serves me right for trying to be helpful!

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

There is no contradiction.  You have not shown any contradiction, and the interp 
makes NO EDIT.

You are demanding that optimisation be disallowed, and that WOULD be a new 
feature.  It is certainly not mentioned as any effect of IEEE_SET_ROUNDING_MODE.

>  The answer to this
>interpretation request need not be "mathematically equivalent wins."

They both "win"!  The rounding mode applies to the actual operations being 
executed.  The point being that after the permitted mathematical 
transformations, there are no operations being executed.

> Indeed, during development of Fortran 2003, there were
>arguments that the "mathematically equivalent" permission did not extend
>beyond a single expression.

The example in the interp does not need that either.

I repeat, there was no intention at any time to disable Fortran optimisation. 
Repeated assurances were made during the development of the "exception handing" 
extension and then the TR that it morphed into, that optimisations would 
continue to be applicable, apart from obvious ones like "no floating-point 
operation (code) motion across rounding mode changes".  There was no code motion 
required to answer this interp.

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

No it cannot.

>which is, after all, what the processor does when upward rounding is
>selected.

No it is not.

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

If you actually write the code in question, rather than making incorrect 
assertions about what the code is equal to, you will of course get a different 
answer.

Your claims here would have the effect of "the processor cannot optimise away 
any of my floating-point operations".  This claim is not supported by the text 
of the standard.  This effect is (imnsho) Not Wanted by the rest of the Fortran 
community (nor, I would hazard, the rest of your own code).

>7.1.5.2.4 continues with the caveat "provided that the integrity of
>parentheses is not violated."  So if the example in 0084 had been
>
>             CALL IEEE_SET_ROUNDING_MODE(IEEE_DOWN)
>             Z1 = (X * Y)
>             CALL IEEE_SET_ROUNDING_MODE(IEEE_UP)
>             Z2 = (X * Y)
>             PRINT *, 'RESIDUAL: ', Z1 - Z2
>
>would a processor still always be allowed to print zero?

Yes.  Or rather, I don't see where I violated any parenthetical integrity - no 
associative or distributive law was invoked.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo. 




More information about the J3 mailing list