> From email@example.com Tue Dec 10 19:50:02 1991
> Date: Tue, 10 Dec 91 19:52:19 -0500
> From: firstname.lastname@example.org (Joe M Leonard)
> To: email@example.com
> Subject: Long C vs. Fortran summary
Here's a summary of the C vs. Fortran posting I did last week. As
you can see, it set a record - 38 replied on the first day!
David Bernholdt (firstname.lastname@example.org) writes:
All of the new stuff in Tektronix's CAChe software is done in C. The
preexisting applications (ZINDO, MOPAC, etc.) are in Fortran as ever.
Based on recurring discussion threads in Usenet's comp.lang.fortran,
there is no consensus yet among scientific programmers in general that C is
much superior and everyone should go off and rewrite everything.
Probably more _new_ scientific applications are now being written in C than
previously. I have heard arguments for performance tradeoffs in both
directions depending on the application.
Martin Norin (email@example.com) writes:
To my knowledge, most applications in organic chemistry are using C
(carbon). Only a few are using B (boron).
jle: He couldn't resist, and neither could I...
John Duchowski (firstname.lastname@example.org) writes (summary):
Folks use C for portability (both among workstations and to PC's) and
it sure beats using BASIC. He pointed out that a recent book on laboratory
automation was written in BASIC, even though most commercial machines use C.
Bill Ross (email@example.com) writes:
I have been busy replacing Amber's MDANAL trajectory analysis
program with one in C called CARNAL (jle: hey, I like it...). A new AMBER
front end w/X graphical interface called Leap is written in C.
Steve Sidner (firstname.lastname@example.org) writes:
Last time I talked to the Tripos people, Sybyl was about 1,500,000
lines of C. It shows. Their science may be debatable sometimes, but the user
interface, integration and rapid availability on new platforms sure isn't.
As you may know, there are FORTRAN to C converters for anybody
wanting to laterally arabesque.
I think it was Joe Sventek who said, "FORTRAN is just portable
assembly language" (jle: I have a button that says that C combines the
flexibility of assembly language with the power of assembly language).
jle: Many others have reiterated Steve's comment regarding Tripos's use of C
Berkley Shands (email@example.com) writes:
C is something you swim in :-) You jump in with both feet and tread
We re-wrote Systematic Search (ala SYBYL Search) in C from a
FORTRAN backend. It took about two man years, with most of the data
structures altered to take the C datastructures into account. The nicest thing
was dynamic memory allocation. We are now at 33,xxx lines of C, with a
MOTIF interface. The program set should soon be available from Tripos (ala
SYBYL again). It does ring searches on linear chains and N membered rings,
Pharmacophore searches (all in the 1 degree (or floating fractional degree)
range) and allows interactive control over the search.
I'll grant you that most C compilers are now very smart about
optimizing calculations. The SGI compiler fails to do common sub-expression
removal or constant folding. The SUN slows down when you use hardware
floating point (snicker snicker).
Alas, FORTRAN was less portable than C, and didn't do forking or
MIMD applications well.
Yvonne Martin (firstname.lastname@example.org) writes:
We write our new programs in C. The Daylight software is also in C as
far as I know.
Mike Peterson (email@example.com) writes:
We have one group and one other postdoc here who do almost all their
programming in C - they're looking at chaos in general, and cellular automata
are often used as models and they often want "visualization" via X windows.
They sometimes call FORTRAN routines though for heavy duty number
crunching like numerical integration of diff. equations. One problem for
some people is the lack of the COMPLEX datatype (and the library routines
that go with them), though this is not a widespread issue.
Jan Radomski (firstname.lastname@example.org) writes:
We sure will, did and do this. Entirely in C (and C++).
Without talking to my boss first, I'm not free to disclose the actual
nature of this (as usual, it is meant to be HOT STUFF)!
Bob Goldstein (U09872@uicvm.uic.edu) writes:
You wanted to know about development in C, so I'm putting in my
vote. I wrote a simulation/data fitting program for chemical equilibria in C
(now available to the public for free) and a program for simulating dynamic
light scattering from flexible macromolecules in C. (In both cases the
availability of yacc for making an input parser to handle the input files was
quite useful. Also the ability to dynamically allocation memory in a portable
way allowed me to move these programs easily among machines.) I am now
fooling around with some novel energy minimization schemes aimed at
proteins in C for similar reasons. In my experience, existing
FORTRAN/chemistry programmers don't like C because (1) inertia, (2)
vectorization, (3) terse syntax, (4) interfacing to existing FORTRAN code. And
it is quite common to believe that a second programming language is as hard
to learn as the first, although this is usually not true, especially for
languages as similar as C and FORTRAN.
jle: two points, first, I'd argue that learning to program is far more difficult
than learning a programming language and second, I think many folks will
have heartburn with the comment that C and FORTRAN are similar...
As to interfacing to existing code, there exist FORTRAN-to-C translators, at
least one of which is free and accessible over the net from netlib. You can
ftp to netlib and get the source for f2c, or just put the line "execute f2c" at
the top of a fortran source file and mail it to email@example.com and the
translated C code will be returned.
Helmut Heller (firstname.lastname@example.org) writes:
I am currently porting my molecular dynamics program EGO from
occam II to C to widen its hardware platform. Originally, it was developed
for a "parallel" Transputer machine, but with the event of more commercial
parallel machines (CM-5, Touchstone, Delta, networks of workstations) it
seems necessary to convert it to C as occam II is only supported on
Andreas Windemut of our group has written an MD program, called
MD, entirely in C.
Both programs are in the public domain and are available by
anonymous ftp from lisboa.ks.uiuc.edu. For EGO, the Transputer-based
program, we also have a guest account which provides access to a 6
Transputer system over the internet. If you would like more information,
please let me know.
Clarke Earley (email@example.com) writes:
While I would not consider my contribution in this area an ongoing
programming development project, I have written a relatively simple
program (ca. 7000 lines) for the display of molecular pictures in C (with a
few minor assembly routines). The program is named MOLYROO, and is
available from QCPE.
This program was developed for use on IBM-compatable PC's using
Microsoft C due to the fact that this package included a reasonably complete
set of graphics routines that was not available with any of the FORTRAN
compilers I was using at the time (This is no longer the case).
I found C to be a very powerful language, and it has a number of
features that I found very useful in writing this program, particularly the
use of data structures. However, while (because?) I have had no formal
training in C, I found programming in this language somewhat more difficult
than using FORTRAN, particularly in the DEBUGGING stages of development.
I also did not find the language to be as portable as advocates claim.
In attempting to learn the language, I ran a simple benchmark to
compare the performance of C vs. FORTRAN in numerical calculations. I
found that C was noticeably slower than FORTRAN (I don't remember the
exact numbers but I think it may have been a factor of ca. 1.25-2.0 times
slower). Similar results were obtained on both a PC using Microsoft C and on
a VAX. I would be interested to know the results of other more
Mike Whitbeck (firstname.lastname@example.org) writes:
I use both C and FORTRAN. In the past I even used a little PASCAL
and PL1. I am now looking into C++.
It has been my experience that C is much more powerful a language
than FORTRAN, especially with respect to memory allocation and structured
programming. Unfortunately, FORTRAN seems to almost always run MUCH
faster. At first this seems odd since undoubtedly the FORTRAN compiler is
written in C and does more work (larger object files - strong variable
typing...). I believe the speed discrepancy is attributable to the very high
level of optimization (for speed) in most FORTRAN compilers.
As an example, I have a PD FORTRAN for an ATARI ST that produces
executables which run twice as fast as those from a $300 'optimized' C
compiler! But the executable file size is 5-10 times larger. Carefully hand-
optimizing the C code for speed evens things up.
Translating FORTRAN to C? Yes, I've done that - it mostly ends up a
complete rewrite. Some things are much easier to code in C than FORTRAN.
I have also used the f2c translator (email@example.com, simtel20).
When using the translator I comment out all the I/O stuff and then hand
code it back into the C output at which time I change all the function names
and type declarations to their ANSI C forms eliminating the need for
FORTRAN library calls. By the way, I don't think C is more portable then
Peter Shenkin (firstname.lastname@example.org) writes:
I do protein molecular modeling, writing my code in C. Also, Jan
Hermans recently told me that he now uses C exclusively, and is rewriting
his FORTRAN codes in C.
Richard Macdonald (email@example.com) writes:
It probably is obvious, but the big commercial chemistry software
houses probably use C. We certainly do at Biosym, although we have a lot of
FORTRAN code, some that we will rewrite in C and some that we won't.
Gary Kedziora (firstname.lastname@example.org) writes:
I'd be interested in hearing what people say about using C in
chemistry applications. I was considering writing a multireference
perturbation theory program in C, but decided against it because nobody in
our group (Shavitt group) knows C, so maintenance would be tough. Also, I'd
like to use a lot of existing FORTRAN routines and the C/FORTRAN interface is
not very portable (I'm told).
Ray Cline (email@example.com) writes:
My major interest in the application of parallel processing to
computational chemistry (MD, Monte Carlo, QMC, path integrals, etc.). In
general, anything that I write from scratch is done in C (and in the future,
probably C++). The features of C that I find particularly useful are the
availability of STANDARD dynamic memory allocation and bit manipulation
routines and the ability to define useful datastructures. The data structures
are particularly useful in parallel programming when it is necessary to
encapsulate data into messages for communication.
There has always been a debate about the speed of FORTRAN vs. other
languages. Modern compilers that use common backend optimizers for all
languages have made this argument meaningless (jle: is this really true,
given the difficulty of recognizing language constructions in FORTRAN vs. C in
the frontend?) The added fact that most programming tools are being
developed for C and C++, not FORTRAN, make C program development more
The major problem that I have is that when other people give me
programs, they tend to be in FORTRAN. The tools available for FORTRAN to C
conversion (f2c and forc) are not fool-proof. This is only a minor problem,
since most of the code development I do from scratch.
Mike Colvin (firstname.lastname@example.org) writes:
The bulk of the massively parallel QC codes at Sandia are written in C.
Our main motivation for using C has been portability and the availability of
datastructures. We've also been programming in C-WEB (C with Tex
documentation interwoven with the source code) and are experimenting
Richard Gililan (email@example.com) writes:
All the Wilson group simulation code (mostly molecular dynamics) is
written in C. We have contemplated moving to C++ but that would involve
more time than we're willing to spend at this point. I've never had any real
problem finding the numerical routines we need. Our group relies heavily
on Numerical Recipes in C but, on occasion, I have used more exotic routines
from elsewhere (netlib, etc.). Links to FORTRAN are trivial.
Matt Clark (firstname.lastname@example.org) writes:
At Tripos, all development is in C for portability, and for the more
advanced capabilities such as dynamic memory using and data structures.
Leif Laaksonen (email@example.com) writes:
What do you mean by chemistry code? If you mean graphics code
then most of the code is written in C or C++ (I believe) (jle: I expect this,
having written a BUNCH of graphics codes in FORTRAN for a VAX a while ago
- the language's not really set up for that...) but if you refer to the so-
called number crunching than most of the code is still in FORTRAN (I believe).
As far as I know there is work going on for rewriting old MD/MM
codes into C. I would be happy to see how close good C coding comes to old
FORTRAN coding in the sense of computational efficiency. The tests I made
on our Cray showed that good vector FORTRAN code is still much faster than
my C code. Does anybody know if this is still the case? On normal
workstations the C code should be pretty close to FORTRAN code.
I don't know what people think but as an old FORTRAN programmer I
now do everything in C and I really would never change back to FORTRAN.
Stephen Daleman (firstname.lastname@example.org) writes (summary):
1. What's taught in the classroom is entirely different from what's
being done in the real world.
2. FORTRAN is still used for number crunching due to the strength of
the support libraries.
3. C (and PASCAL) provide the data structures to construct large
4. FORTRAN9X might provide tough competition to C (when it
5. If new ideas are to be expressed, old style thinking and paradigms
will have to be abandoned.
Doug Allan (email@example.com) writes:
C, after all, stands for Chemistry...
Are you asking for numerical programs being developed in C, or
anything like graphics, etc. (jle: see above, non-graphics). I think programs
like DGauss, DMol, deMon, GAUSSIAN90, etc. will continue to be developed in
FORTRAN, at least as far as I know, while interfaces to actual machines
(windows, frontends, etc.) seem to be written in C (such as Insight of Biosym,
My own coding effort remains restricted to FORTRAN, with a few
splashes of C where FORTRAN just can't cope.
Probably the first codes to be done in C will be those closest to the
machine and with the least numerically intensive demands, i.e. relative
simple molecular mechanics or molecule manipulation programs which
produce screen pictures.
The existence of an IMSL-type facility in C might push such more
numerically intensive codes in the direction of C (jle: do we want multi-
platform codes or codes tailored to each platform - convenience vs. speed?).
Don Kinghorn (firstname.lastname@example.org) writes:
I'm doing nonadiabatic 4-particle variational calculations using an
explicitly correlated basis of gaussian geminals. I'm coding everything in C,
integral formulas, matrix elements, a couple of secular equation solvers, and
optimization routines using simulated annealing and conjugate gradients.
The problem is essentially a HUGH nonlinear optimization problem with a
messy cost function. The main reason I chose C is the development
environment I have available, a NeXT workstation (without a FORTRAN
compiler). I can do algorithm development and prototyping in Mathematica
and Maple, and then code everything in C all in a very friendly environment.
When I have everything written and tested, I'll port it to our 3090 under
AIX (jle: ouch!) for large basis-set calculations.
I don't know if there is any advantage in using C for calculations
like these other than the convenience factor that I mentioned. In fact, it
would have been easier to use Fortran subroutine libraries rather than
writing the code myself, but I'm doing this calculation as a master's thesis
and I wanted to gain programming experience in C. A place where C might
have an advantage over FORTRAN for scientific programming is
implementing code for distributed or parallel architectures. The advantage
being that C is such a nice systems programming language, especially in a
Mark Thompson (email@example.com) writes (summary):
I have developed Argus, an electronic structure code written in C:
(long list of features, comments and a few publications)
Argus is about halfway finished being ported to the Intel iPSC/860