Xref: utzoo comp.compilers:1437 comp.lang.fortran:3998 Path: utzoo!attcan!uunet!ogicse!husc6!spdcc!esegue!compilers-sender From: tim@ksr.com (Tim Peters) Newsgroups: comp.compilers,comp.lang.fortran Subject: Re: IEEE 754 vs Fortran arithmetic Keywords: Fortran Message-ID: <9010242205.AA04208@lunch.ksr.com> Date: 24 Oct 90 22:05:01 GMT Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: Tim Peters Organization: Compilers Central Lines: 43 Approved: compilers@esegue.segue.boston.ma.us > [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 . 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 -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.