Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!i.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ags
From: ags@s.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran versus C for numerical analysis
Message-ID: <3535@s.cc.purdue.edu>
Date: 2 Sep 88 01:38:22 GMT
References: <177@djs.UUCP> <3118@lanl.gov>
Reply-To: ags@s.cc.purdue.edu.UUCP (Dave Seaman)
Organization: Purdue University
Lines: 37

In article <3118@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <177@djs.UUCP>, by samperi@djs.UUCP (Dominick Samperi):
>> o A compiler's license to treat mathematically associative operators
>>   as computationally associative is revoked [in the new standard]. 

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

While you are at it, can you name a language that does less to inhibit
optimization than Fortran?  Fortran is the only language I know that
prohibits modifying aliased subroutine arguments, as in

	REAL A(10)
	CALL SUB(A,A,10)
	 . . .
	SUBROUTINE SUB(X,Y,N)
	REAL X(N), Y(N)
	DO 10 I=1,N
	  T = ...something or other...
	  Y(I) = T**2
	  X(I) = T
     10 CONTINUE
	END

Without this prohibition, optimization would be very difficult, as has been
discussed in this group before.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu