Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!psuvax1!rutgers!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <14214@lambda.UUCP>
Date: 24 Jan 90 23:08:32 GMT
References: <4561@scolex.sco.COM>
Lines: 31

From article <4561@scolex.sco.COM>, by seanf@sco.COM (Sean Fagan):
> [...]
> 1.  Given
> 	a + b + c - e - f;
> 
> I'm happy to let the compiler rearrange things as much as possible to
> generate fast code.  In FORTRAN, by your own admission, you can't do that.
I didn't admit any such thing.  Fortran is allowed to optimize the expression
in any _mathematically_ equivalent way so long as it doesn't violate paren-
thesis.  There are no parenthesis in theis expression at all - so the compiler
can do the operations in any order it likes.

> [...]
> 2.  Given
> 
> 	((((a + b) + c ) -e ) - f);
> 
> The compiler is free to rewrite this, *IFF* the result would be the same!
> If you're using shorts, and overflows are ignored, then, probably, it can do
> what it wants to.  If, however, the result is *not* the same, then the
> compiler cannot do this, and, if it does, it's a bug.

In this case, a Fortran compiler must generate code which is _computationally_
equivalent to the code given.  So, if over/underflow or roundoff (for floating
point) is possible, the compiler must generate code for the expression in
exactly the order given.  This is, in fact, the very purpose of the feature.
Fortran (and most other languages) gives you the flexibility to control the
optimization of expressions, C doesn't (or, didn't - apparently ANSI C
finally joined the modern world in this respect).

J.Giles