[Beowulf] g77 limits...

[Robert G. Brown]

On Wed, 1 Mar 2006, Leif Nixon wrote:

>> Nesting levels of 10+ are not unknown.
>
> Embarrassing. I'll pretend I didn't read that.

Ah, yeah.  Let me embarrass myself even further.  My first foray into
this territory was maybe 1978 or so when I was still a tender young
first year graduate student and the computing world was punch cards and
IBM 370's that were slower and stupider than my palm pilot is today.

I spent one summer working for TUNL, our nuclear lab (that in those days
had fond hopes of recruiting me into experimental nuclear by getting me
to do some "theory" computations for them).  So they hooked me up with a
physicist who had at great length derived a theoretical reduction of the
angular momentum group-theory coupled multichannel scattering equations
for some reaction they were interested in.  His result was a simple sum
over some 9j symbols, if you know what they are.

Well, 9j symbols have 9 different numbers to sum over right there.  But
the numbers aren't all independent and some of them are input or output
(the channel indices you are interested in) while others sum over all
possible internal states.  So THIS sum wasn't too bad -- I can't
remember the formula after close to thirty years but it was something
like six nested sums (in Fortran -- this is where I >>learned<< fortran,
just to perform this computation) not including those hidden by the
routines generating the 9j symbols.

Then came the "interesting" part.  The ACTUAL expression he reduced
involved a some over all the entering and exiting and target before and
target after and intrinsic spin channels for all the particles --
something like 20 Clebsch-Gordan (CG) coefficients (aka 3j symbols).  In
order for angular momentum to be conserved, this nifty thing called the
Wigner-Eckert theorem (that describes angular moementum coupling) and a
bunch of both 3j and 6j symbols had to be summed over, where 6j's are
themselves particular combinations of 3j's with particular (consistent!)
phase conventions to handle the negative -m part of the indices, parity,
and so on.  I am having a hard time remembering what the actual level of
nesting of the code was even WITHOUT the hiding of several levels inside
the subroutines that e.g.  computed 3j, 6j and 9j symbols.

With 66 columns to work with, mind you.  With code that ultimately
filled about a box and a half of cards, each component of which had to
be very expensively written (cards weren't cheap all by themselves in
that quantity), tested, debugged, integrated with the next layer of code
(6j's made of 3j's, 9j's made of 6j's and 3j's, phases and all).  I
recall having to stop and put things like:

C******************** L1 M2 Loop Start ***************************
C******************** L1 M2 Loop End   ***************************

in every two couple of levels in the main loop and renormalize the
indentation just to keep the final expression on no more than 3 or 4
cards with continuations plus a handful on either side doing e.g. the
phases and some precomputed parts.  And at the end, many many CONTINUEs.

Ultimately we discovered that the results differed by something like a
single phase.  A bit of experimentation (and some fairly serious work
with Brink and Satchler in hand) and we determined that it was probably
not in my code.  My mentor/colleague for the summer reexamined his
algebraic results and found the phase and fixed it (unless my aging
memory has reconstructed events and they went the other way around:-).
He published, with results I verified, and as far as I know all I got
was an acknowledgement (certainly nothing like co-authorship or a
separate paper).

And so it goes.  I came out of it with some money (not too much,
really:-), a knowledge of Fortran IV and all sorts of things about
running on IBMs that I eagerly forgot as soon as I could roughly a
decade later after the IBM PC and minicomputers started to supplant its
dominance, and a box full of cards that I kept for years as a sort of
historical relic.  I STILL have a bunch of that code in an archive
directory -- all ready to compute CG coefficients, for example -- and
even went into it from time to time over the years and snarfed e.g. the
YLM code, the PLM code, the CG code, the 6j code -- to use for a few
other fortran projects and ultimately port into C.

Now even the C ports are pretty much dead -- the GSL has it all, has it
better, has it well-tested and efficient.

The point being that yes, there are real computations of real physics
that involve such dastardly things as very deep loops.  This is where I
learned my appreciation of triangular arrays for storing l,m indexed
values, as well.  Memory was precious in those days, and fitting
PRECOMPUTED results into matrices of coupling constants ate (and wasted)
a lot of it.  Too much of it, really -- we ended up having to directly
compute a lot of things instead of building tables.  To get at a
compressed version of even parts of it, one had to do a lot of side
computations using symmetry and phases to avoid recomputing numbers
connected by trivial symmetries.

> Interestingly, you didn't touch on the one actual disadvantage with
> Python's indentation sensitivity; when you move blocks of code around,
> you need to adjust the indentation level of the code when you paste it
> in. But a Sufficiently Smart Editor like emacs makes that easy. (I don't
> know what the vi guys do, but I can't be having with them, anyway.)

Well, that was what I meant when I said that indentation is local, so
you can have inconsistencies between how much you indent in any block
relative to the same block depth in e.g. another program segment or just
another page of the same segment.  You can get there by block copying or
by just forgetting your own indentation scheme.

But yes, emacsoid editors doth save us all from our own indentation
errors -- in C, in perl, in fortran, in python.  And yeah, even in C
mode I spend some time with on-the-fly macros re-indenting things to my
own peculiar standards on some code rearrangements.

It's a bit tricky to make jove/emacs stop using tabs in place of spaces
when it autoindents a line longer than its current conception of a tab
(something that drives me bananas -- I can't stand having tabs in source
code as part of an indentation layout as that NEVER works when you move
code around and doesn't print consistently in all editors, browsers,
whatever) but generally they are marvelous tools.

    rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu