Re: IEEE 754 vs Fortran arithmetic

> [Given that +0 = -0, it's not clear to me that the existence of -0
> breaks anything. Keep in mind that F77 is a permissive standard,
> extensions are permitted so long as conforming programs do the right
> thing. -John]


John, the main problem here is that F77 specifically forbids formatted
output from printing "-0" (pg 13-9, lines 3-5), and while 754/854 never
actually say a -0 has to print as "-0", everyone believes they do
<grin>. I don't think -0 causes any other problems, except for the
inevitable curse of coming to rely on non-portable semantics.


But there are other problems. E.g., the meaning of


X.EQ.Y


is *defined* by F77 to be the value of


              ((X-Y).EQ.0)


(pg 6-10, lines 4-14), and Fortran's usual "must respect parens" rules
prevent a conforming processor from transforming the subtraction into a
"mathematically equivalent" comparison operation (although every vendor
with a comparison instruction cheats here ...). If X and Y are, e.g.,
both +infinity, following the F77 std here would at best signal an
invalid operation exception and yield a nonsense result, while 754/854
insist that the outcome be an exception-free .TRUE..


Perhaps the most widespread "problem" is that 754 vendors tend to like
to evaluate entire expressions in an extended precision and cut back the
result to "storage precision" only at the end. This violates my reading
of both the F77 and 754 stds.


None of the Fortran problems will be repaired by F90.


while-the-marriage-may-not-have-been-made-in-hell-that's-where-the-
      honeymoon-is-taking-place-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.