Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!sdcsvax!sdcc6!ix426
From: ix426@sdcc6.ucsd.EDU (Tom Stockfisch)
Newsgroups: comp.lang.c
Subject: Why I use C instead of fortran
Message-ID: <3597@sdcc6.ucsd.EDU>
Date: 25 Jan 88 04:14:27 GMT
References: <11440@brl-adm.ARPA>
Reply-To: ix426@sdcc6.ucsd.edu.UUCP (Tom Stockfisch)
Organization: University of California, San Diego
Lines: 96

In article <11440@brl-adm.ARPA> lamonts@Sds.Sdsc.EDU (Steve Lamont) writes:
>Herman Rubin <cik@l.cc.purdue.EDU> says
>     
>> I find that I can do much better mathematical programming in C than in
>> FORTRAN....  The major disadvantages are
>> the lack of indirection and casting, and the requirement that a function has
>> an argument.
>
>There are whole bunches more reasons for using FORTRAN for *certain* 
>applications than just power operators and multi-dimensional arrays.

I don't get it.  C *has* multi-dimensional arrays.

>The
>COMPLEX data type, f'rinstance.

True.  This is the only time I use fortran -- when I need COMPLEX, and
I can't use C++.

>...(in fact, there are no 
>INTRINSIC functions, in the FORTRAN sense at all in the C language, at least
>as far as I interpret the term.... please feel free to correct me if I am
>mistaken...;-) ).

That is true, in a formal sense.  However, C implementations are allowed to
translate standard library calls into in-line code.  For example, on the
Celerity machine I work on, the entire math library (except for pow())
is microcoded.  The C compiler will then convert, e.g.,

	sin(x);

into one or two assembler instructions, provided the math library (-lm)
is mentioned in the argument list to "cc".

>I don't see the lack of indirection as a major disadvantage in the type of 
>programs FORTRAN is suited to.  Perhaps I am missing the point here.  Can
>someone please illuminate the subject?

The lack of pointers in fortran means you cannot do dynamic memory allocation.
I've seen many fortran programs that solve a problem whose size is determined
by user input define arrays (and worse, matrices) of huge size just in case
the user asks for a big problem.  When someone runs the program for a
small case, it gets swapped out unnecessarily.  Then when a very large case
is tried (bigger than the arrays were defined for), the whole program has
to be recompiled.

You also can't have an array of pointers to functions in fortran.  This
is a quite handy object for creating a convenient to use non-linear
simultaneous equation solver.  I have written C programs which allow
the user to choose interactively a list of functions (representing
equations) and list of parameters to adjust to satisfy the equations.
Besides array of function pointers, it needs an array of double pointers
for the parameters.

>In some ways, FORTRAN actually *wins*.  For example, named COMMON seems to me 
>to be a better way of handling external variables than simply hanging them out
>in space.  The only disadvantage that I seen in COMMON is that names of things
>in COMMON can be different between subprogram units, making the code harder
>to understand....

...and making errors hard to find.  In C when I add one more variable, I
just add it to my extern.h file which is "#include"ed in most other files.
In fortran, I have to go into a zillion places and make sure the common
blocks are up to date (or is the "include" facility of unix f77 in the
ansi standard?).

>Yes, FORTRAN does run like a slug on some systems.  That alone may militate
>against using it over C.  But, please, don't malign a very useful and, need I
>say, venerable language.
>...		-- Steve Lamont

I try not to get into language wars,  but...
In C you can write interactive programs 
in which you input complex commands which are then parsed and
executed.  In fortran you write programs which just prompt
you to input x and y and then
follow a fixed regimen.  If an interactive
editor, like vi, is a must for editing, why aren't interactive
numerical programs a must for number crunching?

Besides pointers, I often use struct's in
scientific programming.  To work out
the dynamics of a finite lattice of spins that can be, say, up and down,
with nearest-neighbor interactions, it is very convenient to define
something like
	
	struct SPIN {
		enum STATE { DOWN, UP } state;
		struct	*neighbors[COORDINATION_NO];
	}	lattice[LATSIZE];

To do this in fortran, you need many parallel arrays, and the resulting
code is very hard to understand/debug/explain-to-someone-else.
-- 

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