NOT Educating FORTRAN programmers to use C

[Tom Stockfisch]

In article <5303 at tekgen.BV.TEK.COM> kurtk at tekcae.CAX.TEK.COM (Kurt Krueger) writes:
>In article <1024 at sdrc.UUCP> spabdul at sdrc.UUCP (abdul shammaa) writes:
>> why FORTRAN 4? Well, because as the upper managment puts it "Our software
>> has to run on so many hardware platforms".  That's true, BUT, I don't
>> believe that that reason should keep up in the middle ages of software
>> technology. ...   Mind you these are CAE applications which are
>> complex by nature.  So one need not the added burden and limitations of
>> the programming language itself.

>That is probably the BEST argument to keep the implementation in Fortran.
>CAE applications are complex and tend to require a lot of the processor.  With
>the exception of UNIX, you tend to get the best performance with the Fortran
>compiler.

Is this really still true?  Apart from Cray work, I have found I can write
things to run faster or at least the same speed in C.
Also, I wouldn't classify UNIX as an "exception."

>Most of your definition of 'crap' in Fortran is the style of the programmer.

But there is no way to write a loop in Fortran without using statement labels.
And misspelled variable references result in definitions of new variables
initiallized to zero.

>I can generate 4x that type of 'crap' in C.

I agree.  Getting an old f77 type to switch to C must be accompanied by
teaching them how to write reasonable code.

>It might enlighten you to read a book by Kernighan (THE K in K&R) and Plauger
>called "The Elements of Programming Style".

Isn't this the book that preaches to make it right before you make it fast?
Also, this ignores the importance of memory complexity, where malloc()
helps out enormously.  In Monte Carlo simulations I have done recently
on an 8meg machine, the most
important thing to do was to reduce memory requirements so the program
could run in the background without swapping.  This made orders of magnitude
difference in run time.

>I'm  still a firm believer that if you want performance on multiple
>platforms, Fortran (but f77 PLEASE!) is still the way to go.

I've heard this time and again, and I don't think it is true any longer,
except possibly for vectorizing machines.  I've used machines that didn't
*have* a fortran compiler.

>Fortran does some things real nice (try passing a variable dimensioned 3-d
>array into a C function - UGH!

double	arr1[10][20][30], arr2[40][50][60];

main()
{
	int	m1, m2, m3;
	double	*arr3;	/* really m1Xm2Xm3 */

	doSomething( &arr1[0][0][0], 10, 20, 30 );
	doSomething( &arr2[0][0][0], 40, 50, 60 );
	getSizes( &m1, &m2, &m3 );
	arr3 =	(double *)malloc( m1*m2*m3*sizeof(double) );
	doSomething( arr3, m1, m2, m3 );
	...
}

void
doSomething( a, nlayer, nrow, ncol )
	double	*a;
#		define A(i,j,k) a[ ((i)*nrow + (j))*ncol + (k) ]
{
	...
	A(1,2,3) =	...
	...
}

As illustrated, fortran's variable-dimensioned array arguments can be
simulated in C with little effort.  Simulating dynamically allocated
arrays in Fortran is extremely difficult.

> , or dealing with COMPLEX variables),

>The optimizers are generally
>VERY good at turning array reference operations into the equivalent C pointer
>reference.

They can not reasonably perform this optimization for arrays of indices,
such as might be used in a pivoting scheme for Gaussian elimination.

>This argument will weaken as years go by, but it could very well be a
>different language than C that we will be discussing.  I guarantee that
>Fortran will still be the 'other' language discussed.

Fortran what? 4?, 77?, eighty-twelve?  The "other language", in a few years
will probably be C++ (unless I'm being overly optimistic), which has
much more in common with C than F-whateve-comes-after-77 has in common
with F77.
-- 

|| Tom Stockfisch, UCSD Chemistry	tps at chem.ucsd.edu