[net.lang] C for physicists

nelson@avsdS.UUCP (06/18/84)

#
I was once and will soon again be a geophysicist. At the US Geo. Survey
in Menlo Park we were using C for new software. Many universities are
also using C in their geofizzies deptartments. Over 3 years ago the
Survey ported the IMSL library to UNIX f77. It is a pain, but not hard
to call f77 programs from C and vis-a-versa. UNIX f77 is slow, but C
is not - let's face it, someday the scientific community will have to
grow out of FORTRASH. Aside from complex variable types, FORTRASH has
nothing going for it.

On the matter of fixed array sizes: all compiled languages that I currently
know of require a constant array size declaration (the linker needs to know).
However, the subroutines only need dummy arguements [note: not true of
Pascal, and a real tragedy for scientists!]. You do not need to know
about pointers to write scientific procedures in C! You do need to know
the size of all but the last dimension in multi-dimensional arrays.

	C		FORTRAN
________________________________________________
float x[];		real x(1)
float x[][N];		real x(n,1)
float x[][M][N];	real x(n,m,1)

Note that the dimension sequence is reversed (x,y,z vs. z,y,x).
The parameters m and n can be passed as args in FORTRAN, but in C
must be compile-time constants. If you can include the source code
with your program, this is no hardship. If not, the routine is presumably
in a library, and someone has presumably spent time to ensure that it
runs properly before committing it to general use. At that stage
the array references as above can be recoded into pointer references.
This is not the best state of affairs, but is a very reasonable
alternative to staying with FORTRAN.

Having coded for 13 years in FORTRAN and 4 in C, I can say that much
better code can be written in C - the control structures are
"light years" ahead of F. Most of my programs are also designed to be
used by others, meaning they have to be somewhat "user-friendly",
meaning I need decent string support. Also, in seismology we are working
more and more with databases. Things like this are just disgusting to do
in FORTRASH.

For UNIX users that insist on FORTRAN there is not only RATFOR, but
also ECL - a superset of RATFOR that is much more C like. The ECL
preprocessor also produces F code with sensible line numbers, indentation,
and sensible variable names. Ever try to comprehend the output of RATFOR?
Frankly, the idea of preprocessors is horrible - one more step, too much
time, and then try debugging the program!

An aside on multi-dimensional arrays: I now write all my C programs such
that multi-dimensional arrays are data structures that contain array
as well as the sizes of its dimensions and other pertinent information
about the data. Thus in C I can call a procedure like "massage_data(dataset)",
instead of "massage(data, n1, n2, n3, ...) in FORTRAN.

Glenn Nelson	Ampex Corp., Redwood City, CA
		...!{nsc|hpda|megatest|amd70}!fortune!dsd!avsdS!nelson
		415-367-2499

	"See earth-shaking events in your own home!"

alexc@dartvax.UUCP (Alex Colvin) (06/26/84)

There's been a lot of loose talk here about the demerits of Fortran and
the merits of C.  Thosae who've already grown tired of this subject are
encouraged to type whatever it is that gets them to the next article.

As far as I can see, the original point here is that UN*X has a terrible
implementation of Fortran.  I don't think anyone refuted this.  All they
came up with was the counter that C is what you should be using on UN*X.
I'd have to agree.  UN*X doesn't seem to support any other language as well.
Those who need Fortran, who have large Fortran applications, probably 
shouldn't be using UN*X.

The C proponents have pointed out a number of failings in Fortran.  The
control structures of C are a little more sophisticated than those of Fortran.
I don't know whether F77 allows you to pass functions around, implementing
yr own control structures.  It doesn't usually allow or encourage recursion.
Etc. etc.

On the other hand, the C fans I know seem pretty blind to their favorite
lingo's failings.  C, for example, doesn't really implement arrays.  Just
pointer arithmetic.  I admit that the latter is useful, but think about
trying to add array bounds checking to a C program.  It's not unusual to
have this feature available for Fortran.

Then there is the C expression syntax.  15 levels of operator precedence.
Some associate left, others right. 9 kinds of prefix operator.  33 infix.
Two enfix, and the ?:.

In APL at least, with its half a hundred operators, they decided that no one
could be expected to remember the precedence, so there's a simple rule
(broken only for functionals!).

Consider also (4)*3.  Now (int)*ptr.  How about (A)*B?

			... Just tired of C
			    A. Colvin