[Beowulf] g77 limits...

[Jim Lux]

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
>recenter your indices.
>
>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.
Spacecraft Radio Frequency Subsystems Group
Flight Communications Systems Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
tel: (818)354-2075
fax: (818)393-6875