(j3.2006) J3 09-155 interp letter ballot #18 due 23-Mar-2009
Tue Feb 24 03:18:00 EST 2009
> --- --- F03/0065 Relational equivalence
> NUMBER: F03/0065
> TITLE: relational equivalence
> KEYWORDS: transformation, relational equivalence, mathematical value
> DEFECT TYPE: Interpretation
> STATUS: Passed by J3 meeting
> REAL X
> X = ... some value ...
> IF( X+3.0 .EQ. 3.0 )...
> be transformed into
> IF( X .EQ. 0.0 )...
> by the processor?
> References are to J3/04-007.
> 126.96.36.199 Evaluation of numeric intrinsic operations has a discussion of
> "mathematically equivalent", "mathematical value" and "computational
> 188.8.131.52 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 184.108.40.206 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
> possible computational values
> 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
> 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.
> 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.
More information about the J3