(j3.2006) (SC22WG5.4757) [ukfortran] Provisional result of interpretationsballot 3, N1933

[Malcolm Cohen]

>On Sep 4 2012, Malcolm Cohen wrote:
>>
>> I think that F03/0065 ballot result should be "C", since it is 7 Y and
>> 2 N.
>
>From that, I assume that there are no formal rules.

You are mistaken.

It passed the vote 7-2.  However, the formal rules allow for /INTERP subgroup to 
withdraw an interp that would have passed the vote if the negative votes or 
positive comments raise a new technical issue that in their view requires 
further consideration.

Thus normally whenever there is any negative vote or adverse technical comment, 
the provisional result is declared to be "C"; that is conditionally passes 
subject to /INTERP subgroup review of the comments.

>> IMO there is not obviously any new technical content in the No votes (F66 and 
>> F77 not being exactly new!), but C is ok to defer to J3 to confirm that we 
>> don't want to revise the answer.
>
>At least you and I are still completely at cross-purposes.  My point is
>that we have been sweeping this issue under the carpet for the past 50
>years,

The discussion might seem long, but I think 50 years is a bit of a stretch.

> and the direction of its commentary is towards the slippery slope
>that we tried but failed to avoid when designing C90 in WG14 :-(  Please
>don't let Fortran follow the semantic path that C and C++ have taken!

Arguments about the C standard are completely irrelevant to this.  Please do not 
bring red herrings into the discussion.

>The interpretation is:
>
>   QUESTION:
>
>   Given
>     REAL X
>     X = ... some value ...
>   may
>     IF( X+3.0 .EQ. 3.0 )...
>   be transformed into
>     IF( X .EQ. 0.0 )...
>   by the processor?
>
>   In Fortran 2003, 7.1.8.5 Evaluation of relational intrinsic operations
>   says
>     "Two relational intrinsic operations are relationally equivalent if
>      their logical values are equal for all possible values of their
>      primaries."
>
>   On a machine where addition of 3.0 to a small value is not exact, the
>   logical values for X+3.0==3.0 are not the same as X==0.0 for all
>   possible values of X, therefore it would seem that this transformation
>   would not be possible.
>
>Consider a conventional implementation where operations are done in
>64-bit and REAL is 32-bit.  X+3.0==3.0 is not the same comparison as
>either X==0.0 or as in 'X=X+3.0;IF(X ==3.0)', but it is as
>'REAL(KIND=KIND(0.0D0)) Y; Y = X+3.0D0; IF (Y == 3.0D0)'.  Are we now
>forbidding such implementations?  The point is that the last paragraph
>in the interpretation implies that.

You need to express yourself more clearly with line breaks and quotations. 
Like, what on earth are you talking about?  The last paragraph in the 
interpretation says
   "The erroneous example has been removed in Fortran 2008."
That does not say anything about your example, it says something about removing 
an erroneous example.  The example was erroneous in that it contradicted 
normative text except on machines with near-infinite precision or when 
sufficient additional (unstated!) information was known about the possible 
values of X.

>I regret that I didn't think of that example to give in my objection.

The interp asks whether
   X+3.0==3.0
can be turned into
   X==0.0
on a machine where for some (small) values of X, X+3.0==3.0 is not equivalent 
(has a different truth value) to X==0.

>I am happy for J3 to interpret my objection as requiring that:
>
>    a) The interpretation is changed to say that X+3.0==3.0 cannot
>be treated as X==0.0 under all circumstances, but that it may be valid
>to do so in some processors under some circumstances (unspecified).

You are making an enormous unfounded logical leap here.

The standard clearly states that it can do
   "if their logical values are equal for all possible values of their 
primaries".

There are many circumstances where this is possible, e.g. there might be a 
preceding statement like
   X = ANINT(Y)/10.0

The interp you are rejecting says
  "No, the transformation is not permitted unless it gives the same
   answer for all possible values (of X and X+3.0)."

Note the "unless".  So if in a particular situation, there are no bad values of 
X possible, obviously the processor can make the transformation.  What's more, 
the user cannot tell!  (Unless it shows up via IEEE_INEXACT or something.)

>    b) No implication that the value X+3.0 must be converted to the
>precision of REAL before the comparison is included in the
>interpretation.  And THAT is the aspect that I really want to hang
>on to!

I simply do not see where you think it says anything of the sort.  It does not. 
X+3.0 can be evaluated as any mathematically-equivalent expression, and 
evaluating the same expression in a higher precision is a computational 
difference not a mathematical difference.  Infinite precision is fine if you've 
got it.  NOTE: The evaluation of X+3.0 is not covered in ANY WAY by this 
subclause.

Perhaps it would have been clearer if it asked whether it was ok to evaluate
   X==1.0
as
   X-1.0==0.0
on a machine where etc etc etc, but the example in the interp is simply the old 
example from the old standard, that is why that was chosen.

Honestly, this is only about the relational operation giving the right answer, 
not about how the operands are evaluated.

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