(j3.2006) J3 09-155 interp letter ballot #18 due 23-Mar-2009

[Robert Corbett]

> ---  ---  F03/0065  Relational equivalence

> NUMBER: F03/0065
> TITLE: relational equivalence
> KEYWORDS: transformation, relational equivalence, mathematical value
> DEFECT TYPE: Interpretation
> STATUS: Passed by J3 meeting
> 
> 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?
> 
> References are to J3/04-007.
> 
> 7.1.8.3 Evaluation of numeric intrinsic operations has a discussion of
> "mathematically equivalent", "mathematical value" and "computational
> results".
> 
> 7.1.8.5 Evaluation of relational intrinsic operations has "Two
> relational intrinsic operations are relationally equivalent if their
> logical values are equal for all possible values of their primaries."
> 
> "values" in that context is ambiguous to me.  Is it the infinite set
> of mathematical values or is it the finite set of hardware
> representable (computational) values?
> 
> My brief scan of F2003 finds that "values" without any adjectives
> means what the hardware can represent.
> 
> Assuming "values" in 7.1.8.5 means what the hardware can represent,
> then I conclude that the transformation cannot be done.  However, Note
> 7.22 shows "I > J" transformed into "J-I < 0"; which is not true for
> the finite set of hardware values (due to undefined behavior of
> overflow), but is true for the infinite set of mathematical values.
> 
> I believe that "possible values" should be changed to either:
>   possible mathematical values
> or
>   possible computational values
> 
> ANSWER:
> 
> Since it can be undecidable whether expressions are mathematically
> equivalent, it is clear that the permission to evaluate mathematically
> equivalent expressions means "if an expression can be determined to be
> mathematically equivalent it can be used instead."
> 
> Even in cases where it is easy to determine that expressions are
> mathematicaly equivalent, it can be formidably expensive to determine
> that they are equivalent for the finite but sometimes very large set of
> "all possible computational values of their primaries."
> 
> The term "different computational results" includes the case that one
> expression does not produce overflow when evaluated computationally for
> some set of computational values of its primaries, while a
> mathematically equivalent expression does produce overflow when
> evaluated computationally for some members of that set of values of its
> primaries.
> 
> One can imagine a processor that cannot evaluate I > J, but it can
> evaluate I - J and then examine the sign.  This transformation thus has
> to be allowed for all values, not just for those computational values
> for which no overflow results.
> 
> Therefore, the term "all possible values" refers to mathematical values.
> 
> EDITS:
> 
> None.
> 
> SUBMITTED BY: Fred Tydeman
> 
> HISTORY: 05-192    m173  F03/0065 submitted
>          09-150    m187  Passed by J3 meeting

The interpretation the committee has given for F03/0065 is a poor choice
for a language that might be used for floating-point computations.
While Fred Tydeman gave a good example, there are better examples. 
Consider the expression

       X + 1.0 .EQ. Y + 1.0

When an expression such as this appears, it is almost certainly
intended to yield different behavior from the expression

       X .EQ. Y

Nonetheless, the indicated transformation will make the code run faster,
which will make it a tempting optimization.

The first Fortran implementation I used did the transformation of
I > J to I - J > 0.  It did so, not because it had to, but because it
was emulating another implementation that did that transformation.
That specific transformation made programming unnecessarily difficult.

No other language of which I am aware allows such tranformations.  No
machines that are likely to support a modern Fortran implementation
would have trouble supporting the strict relational semantics.  I do
not think this interpretation is in the best interest of Fortran users.

Robert Corbett