Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran versus C for numerical analysis
Message-ID: <3183@lanl.gov>
Date: 2 Sep 88 20:04:48 GMT
References: <3535@s.cc.purdue.edu>
Organization: Los Alamos National Laboratory
Lines: 21

From article <3535@s.cc.purdue.edu>, by ags@s.cc.purdue.edu (Dave Seaman):
>>This is MORE restrictive than the significant parenthesis of Fortran.
>>The main complaint against Fortran was that it restricted optimization
>>too much.  I haven't seen this in any of the ANSI draft standards yet.
>>I hope I won't.
> 
> I am puzzles by this.  After close reading of the standard, I don't see
> how it is possible.  Can you give an example of a Fortran expression that
> illustrates your claim that Fortran can treat mathematically associative
> operators as computationally associative?

You almost gave one yourself.  The expression A+B+C may be evaluated 
as (A+B)+C, A+(B+C), or (A+C)+B.  Fortran is free to do the calculation
in any of those orders.  But, if the original expression had been
parenthesised, the order would have been required.  The only associative
optimization that is explicitly prohibited by the standard is violating
parenthesis integrity (ANSI X3.9-1978, section 6.6.3).  The processor
is therefore free to do other optimizations (ANSI X3.9-1978, section 1.4).

J. Giles
Los Alamos