Xref: utzoo comp.compilers:1442 comp.lang.fortran:4005
Path: utzoo!attcan!uunet!nih-csl!lhc!adm!cmcl2!yale!mintaka!spdcc!ima!esegue!compilers-sender
From: wsb@eng.Sun.COM (Walt Brainerd)
Newsgroups: comp.compilers,comp.lang.fortran
Subject: Re: IEEE 754 vs Fortran arithmetic
Keywords: Fortran
Message-ID: <144188@sun.Eng.Sun.COM>
Date: 25 Oct 90 17:03:07 GMT
References: <9010242205.AA04208@lunch.ksr.com>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: wsb@eng.Sun.COM (Walt Brainerd)
Followup-To: comp.lang.fortran
Organization: Compilers Central
Lines: 62
Approved: compilers@esegue.segue.boston.ma.us

In article <9010242205.AA04208@lunch.ksr.com>, tim@ksr.com (Tim Peters) writes:
> 
> 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 ...).

The referenced lines begin:

"If the two arithmetic expressions are of different types, ..."
                                           ^^^^^^^^^^^^^^^
so this does not apply if X and Y both are real, for example.
This text is there to explain how to do type conversion when
X and Y are different types.  Thus, I don't think compilers that
use a relational operator are "cheating".

> 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.

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)
Yes, there are some words that indicate when you should convert from one
precision to another, but there is nothing that says how much any particular
precision there should be for anything (there are requirements on how
equivalence must work between them, but this only affects how stored results
must align, not expression evaluation and not the values stored).

> None of the Fortran problems will be repaired by F90.

The real "problem" is: according the the F77 _standard_, there is no way to
be sure that real arithmetic is done by any particular scheme, so any program
that tries to depend on a specific result (i.e., comparing two reals for
equality) or expecting the result of any real operation to be precise within
certain limits, is nonportable.  You certainly may have your own criteria
about how things should work and pick a vendor that does things that way, but
there is no help for you in the standard.

The only reasonable "repair" I can think of is to require all arithmetic to
be done as IEEE 754, or some such, a position that clearly is not acceptable
to all vendors this year.

The new KIND mechanism in Fortran 90 will at least allow the programmer to
indicate that a variable has a certain number of digits of precision; I think
this should help some.
--
Walt Brainerd        Sun Microsystems, Inc.
wsb@eng.sun.com      MS MTV 5-40
                     Mountain View, CA 94043
                     415/336-5991
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.