Re: IEEE 754 vs Fortran arithmetic

In article <144188@sun.Eng.Sun.COM> wsb@eng.Sun.COM (Walt Brainerd)
writes:
>In article <9010242205.AA04208@lunch.ksr.com>, tim@ksr.com (Tim Peters)
>writes:
>> [X.EQ.Y means ((X)-(Y)).EQ.0 under F77 rules, and this creates
>> problems under 754]
> [walt explains that this clause applies only when X and Y are
> different types]


Yes, agreed -- thanks for clarifying. The example should have had,
e.g.,


DOUBLE PRECISION X
REAL Y


The conclusions are unchanged.


>This text is there to explain how to do type conversion when
>X and Y are different types.


I agree that was the intent. Unfortunately, that's not what the F77
text says.


A possible correction: F90 may have fixed this problem after all. I
noticed today in the S8.115 draft of F90 that the goofy phrasing of the
F77 standard is gone, replaced by words that clearly get at the type
conversion intent without F77's harmful overspecification. Hope the new
text survives.


>> [tim whining about various 754 vendors evaluating entire expressions
>> in an extended precision before cutting back to "storage precision"]
>Since there is nothing in the F77 standard that indicates how much
>precision should be used for anything, such an evaluation cannot
>violate F77. (IMHO) ...


We disagree, but launching into an argument about what F77 does &
doesn't say would take us out of the "754 vs Fortran" topic, so I'll
just sketch the opposing view below. More important to the topic at
hand is that the extended precision gimmicks are clearly against both
the letter and the spirit of the 754/854 stds, under any implementation
that's claiming to map Fortran's "+" "-" "*" "/" REAL and DOUBLE
operator symbols into the addition (etc) operations defined by 754/854.
The results of the 754 operations are defined down to the last bit, and
any implementation doing the extended-precision stuff cannot meet those
definitions (e.g., because of double rounding errors).


conforming processor from, e.g., evaluating "X+Y" in


REAL X, Y, Z
Z = X+Y


in an extended precision (or, for that matter, in a reduced precision,
or even unconditionally evaluate all sums to -6.5!), I do not agree that
the std allows that freedom across the entire RHS in


Z = X + (Y + Z)


or even in


Z = X + Y + Z


Section 6.1.4 clearly defines the type of all *sub*expressions in the
above to be REAL, and to say that the "mathematically equivalent"
freedoms allow one to carry *more* than REAL precision out of the REAL
subexpressions into their contexts is to squeeze all meaning out of
"mathematically equivalent", Fortran's notion of type, or both.


Since F77 is not in any sense a formal or rigorous std, this is a matter
of interpretation (but so is everything else <grin>). I don't feel it's
*reasonable* to take an interpretation that reduces parts of the std to
meaninglessness.


> [walt patiently <grin> explaining that Fortran cannot guarantee
> results consistent with what 754 requires]


Yes, of course. But Fortran can & should change to allow 754 vendors to
meet both stds simultaneously without logic-chopping and brutal
contortions. The change in S8.115 to the definition of relationals is a
good example of what can be done to further this end.


It is unfortunate that F90 didn't consciously address 754/854 issues.
It is also unfortunate-- & more so! --that 754/854 did not consciously
address language binding issues from the start. As other people here
are pointing out already, the *real* pain isn't the (very) few areas in
which 754 and Fortran flat-out contradict each other, it's the many
areas in which the 754 features are a poor fit with Fortran (and C ...).
What to do with a NaN in an arithmetic IF is a darned good question.
Optimize


IF (X.NE.X) PRINT *, 'Found a NaN!'


out of existence because X.NE.X is relationally equivalent to .FALSE.
and the 754 user is in for more exceedingly nasty surprises. Have some
vendors using their extended-precision gimmicks and others not and the
fact that 754 defines a "portable" arithmetic is reduced to an academic
footnote. Etc. Etc.


some-de-facto-std-will-eventually-arise-out-of-this-mess-but-for-now-
      it-is-indeed-a-mess-ly y'rs - tim


Tim Peters Kendall Square Research Corp
tim@ksr.com, ksr!tim@harvard.harvard.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.