# [Beowulf] g77 limits...

Jim Lux James.P.Lux at jpl.nasa.gov
Thu Feb 23 14:09:04 PST 2006

At 12:15 PM 2/23/2006, Robert G. Brown wrote:
>On Thu, 23 Feb 2006, Jim Lux wrote:
>
>>All art and creativity is enhanced by limititations of the medium. I, for
>>one, find that the fact that FORTRAN has a native complex type (since IV
>>days, and maybe even FORTRAN II had it) and exponentiation as a native
>>operator has been more useful than structs and pointers (all that dynamic
>>allocations stuff just gets you into trouble) which only get you into
>>trouble anyway).  And FORTRAN does have the EQUIVALENCE statement, which,
>>especially with named common, can be used to create a form of struct.
>
>Yeah, but try allocating a triangular array to hold Y(l,m) efficiently,
>with l \in (0,l_max) and m \in (-l,l).  Try doing that for I(L,L',L")
>(Gaunt numbers or 9j symbol tables).  Try allocating structs that have
>object metadata as well as the actual data.  Try building or working
>with linked lists, trees, all sorts of recursive data structures.

Hold triangular arrays efficiently?  There's zeros in the array, why not
store them in memory? If a problem is worth doing, it's worth doing with
brute force.  If the hammer you have isn't big enough, buy a bigger
hammer.(or supercomputer, as it were).  Of such a straightforward analysis
did Seymour Cray make his fame.

As for metadata, that's what the chalkboard in your office is for, isn't it?

Next thing you know, you'll be advocating that we can split up big problems
into lots of little ones and use a room full of these toy things called PCs
to do the calculations.

>(Older) Fortran is (was) just great if all you want to do is work with
>rectangular matrices with indices that run from 1 to N per dimension, or
>don't mind writing lots of silly little displacement snippets to
>
>Then there are the SERIOUS tricks.  Allocating a whole block of memory
>as a flat chunk, then repacking its addresses into pointers as a
>multidimensional array such that you can pass the whole thing into e.g.
>an ODE solver that expects to get a vector and only a vector as input,
>but STILL BE ABLE TO MANIPULATE ITS CONTENTS as an addressable array
>with no funny displacement arithmetic when evaluating derivatives and
>jacobeans.

True enough.  But there might be a limit to this.  Consider the gyrations
that any language goes through to provide a simple representation of
certain operations that are efficient on the target computer. A good
example would be FFT butterflies on a DSP oriented CPU (with hardware that
supports stride indexing and in-place bitreversed addressing), or even
certain vectorizable computations (filters with long sequences of multiply
and accumulate).

>>Sure, FORTRAN's not a string processing language (it's FORmula
>>TRANslation, after all). It's meant to do REAL science and engineering
>>work, like finite element models for weather prediction and nuclear
>>weapons design, or orbital mechanics calculations for ICBMs and Apollo.
>>If you want to move data from one column to another you can use RPG or
>>COBOL or plugboards on your Electric Accounting Machinery.  You want to
>>do that namby pamby character and string stuff that english and
>>linguistics types are interested in, or work in abstract worlds, use
>>SNOBOL or LISP.
>
>No arguments, except that REAL science and engineering is not by
>hypothesis flat, rectangular, or (only) complex.  Fortran does decent
>formula translation type programming, but it is not terrible flexible or
>powerful otherwise.  It has obvious weaknesses -- things that are just
>plain painful to do -- for all that it does what it does and was
>"meant" to do quite well.  It wasn't designed to write editors or
>operating systems in, or to work well with symbols in general or memory
>in general.

Actually, I find it amazing that there's still an awful lot of brand new
FORTRAN code being written, considering that the language was invented to
solve the problems that were current in the late 50s (and had research
budgets to pay for them), and has all these clunky aspects.

And yes, while it's clunky, FORTRAN is no worse than, say, assembler, for
some of these non-optimal applications: Over the past 30 or so mis-spent
years, I've written, in FORTRAN, a couple compilers, a couple quasi
RealTime OS kernels, a B-tree based file system with transparent mirrors
and caches with multiple simultaneous accesses on dual port drives, a
variety of debuggers, an 8086 simulator, and a optimum path router for
aircraft.  I am heartily glad that should I have to duplicate any of these
things, I wouldn't have to use FORTRAN today.  But, back in the day,
FORTRAN is what you had (Imagine writing a shared filesystem in COBOL!),
and it was a heck of a lot easier to use than, e.g. BAL.

James Lux, P.E.