Robert G. Brown wrote:
On Tue, 20 Nov 2007, Donald Shillady wrote:
Hi, I am one of those old grey-haired Professors who spent years since
1963 using variants of FORTRAN with time out for four years of enforced
Burroughs ALGOL and then back to FORTRAN. In Chemistry education there
is an added problem of students who want to avoid mathematics. I taught
Physical Chemistry Laboratory for some 30 years and found BASIC/GWBASIC
is a way to introduce students to sequential coding that could lead to
later use of other languages such as f77, C++ or PASCAL. In a lab
course it is easy to write some special purpose program in GWBASIC for a
given lab report and the concept of programming takes second place to
the formulas used; often such programs are less than a single page. In
my area of Quantum Chemistry there are a few folks pushing C++, but I
would estimate that 95% of most huge programs such as GAMESS or GAUSSIAN
are in some form of FORTRAN. Personaly I want to "think" in formulas
not in pointers and the pointers just add another layer of complexity to
what is probably already complicated mathematics. After all that is
Sure, but while pointers CAN be used to write obfuscated code in C -- a
practice I totally eschew -- they can also be used to work miracles in C
creating "matrices" that are not square, and do not start with index 0
or 1, and do not waste space, and map into a specific vector so that one
can write general purpose subroutines that act on vectors and use them
for arbitrary tensor forms. When you combine this with C's ability to
specify and manipulate structs (which are the old-timey objects that
preceeded c++ and continue to be the basis of OO programming in C today)
you have a truly amazing ability to generate custom data objects that
are both efficient and natural for -- translating formulas.
To pick a single example, if I were to have a four-dimensional set of
differential equations where the indices were e.g. particle number,
principle quantum number n, angular momentum indices l and m, where n,
l, and m are range restricted so that the most efficient allocation of
memory would be a triangular one and where one wishes to access the
particle by means of something like x[i][n][l][m], it would be nearly
impossible to build the array in Fortran without (effectively)
manipulating pointers. It is easy in C -- the code to lay out the
matrix would take me maybe thirty minutes to write and another thirty to
test. If one then wishes to (for whatever reason) write coupled
differential equations to generate x_inlm(t) from some initial state --
well, most ODE solvers only work on vectors of ODEs.
In fortran this leaves one working with an abomination of displacement
arithmetic on a vector -- I'm sure we've all written X[I + IMAX*N +
IMAX*NMAX*L...] (which isn't even right -- it has been years since I've
had to do this and thank God I never will have to again) to somehow
access a vector in terms of matrix indices. The resulting code is both
unreadable and impossible to debug.
You haven't tried anything F90 or above. Take a look at some tutorials.
It's basically the same as in C now. You have allocation, pointers
(if you want them).
Pascal was fascist because it was basically a learning language and was
trying to force undisciplined students to be absolutely disciplined
about declaring, typing and so on their variables. While I dislike its
rigidity, its goal is a good one and a programmer in ANY language is
unwise if they are too cavalier about their data typing or too sloppy
about data declarations. Fortran's implicit types, for example, mean
that variable names often look "odd" (even though I find nearly 20 years
after I last wrote fortran that I tend to use i-n as the first letter of
integer variables in C, sigh).
Not anymore. In F90+ (anything F90 or later), you can declare any variable
to be any type. You have structures as well. You also don't have to indent
6 spaces anymore (in Fortran speak it's called free-form).
Finally, for a long, long time the machine code produced by various
fortran compilers was testably faster and PASCAL would be a counter
example of lucid slowness! As far as a text, I never used one, I am
coasting along on a two week course in FORTRAN II in 1963 and along the
way just looking at published routines and learning what works and what
does not. For learning I would still suggest BASIC/GWBASIC.
Fortran compilers were, without question, well written and efficient for
a lot of numerical code. Probably still are. The very ability to
generate freeform arrays and so on I describe above CAN lead to very
efficient C code programs, or one can generate data structs in orders
that actively defeat streaming memory access optimization because they
are (paradoxically) easier to read and think about that way. Sometimes
there really is an ease of coding/performance trade off, after all.
Literal translation of formulas may not be efficient, and as has already
been demonstrated, can all too easily lead to wrong answers when e.g.
summing series, especially alternating or long tail series.
Fortran has always been great on linear algebra, though, BECAUSE its
square matrices and linear vectors and lack of object/pointer
flexibility made it possible to really work on linear algebra algorithm
optimization. The one other feature of fortran that I miss is its
binary exponentiation operator. In C exponentiation is a library
function. In fortran it PROBABLY is as well -- it certainly requires a
call to a complex piece of code as opposed to a simple code fragment
however it is represented in a program -- but y'know, it really is
easier to write and understand code like a*b**i or a*b^i rather than
a*pow(b,i).
In Fortran it's always been x**y. The good compilers let x and y be any
data types (I've not tried using a complex as the exponent though).
Jeff
_______________________________________________
Beowulf mailing list, [email protected]
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
