[Beowulf] Teaching Scientific Computation (looking for the perfect text)

[Jeffrey B. Layton]

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