Wed, 24 Oct 90 18:05:01 -0400

Related articles |
---|

IEEE 754 vs Fortran arithmetic robertsj@admin.ogi.edu (John Roberts) (1990-10-22) |

Re: IEEE 754 vs Fortran arithmetic burley@world.std.com (1990-10-24) |

Re: IEEE 754 vs Fortran arithmetic henry@zoo.toronto.edu (1990-10-24) |

Re: IEEE 754 vs Fortran arithmetic tim@ksr.com (Tim Peters) (1990-10-24) |

Re: IEEE 754 vs Fortran arithmetic dik@cwi.nl (1990-10-25) |

Re: IEEE 754 vs Fortran arithmetic wsb@eng.Sun.COM (1990-10-25) |

Re: IEEE 754 vs Fortran arithmetic eggert@twinsun.com (1990-10-25) |

Re: IEEE 754 vs Fortran arithmetic wsb@eng.Sun.COM (1990-10-25) |

Re: IEEE 754 vs Fortran arithmetic sjc@key.COM (1990-10-26) |

Re: IEEE 754 vs Fortran arithmetic diamond@tkov50.enet.dec.com (1990-10-15) |

[3 later articles] |

Newsgroups: | comp.compilers,comp.lang.fortran |

From: | Tim Peters <tim@ksr.com> |

Keywords: | Fortran |

Organization: | Compilers Central |

Date: | Wed, 24 Oct 90 18:05:01 -0400 |

*> [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

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.