[Beowulf] g77 limits...

[Robert G. Brown]

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.

(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.

Truthfully I agree -- I do wish that C had a binary exponentiation
operator (although I understand why it does not -- exponentiation is
most definitely a library call, regardless, with some pretty serious
bounds on its valid argument space.  Nowadays it has decent complex
support, although I rarely use it and the OO C++ people would argue that
their's is better.  Even there, though -- in C it is easy to define a
struct typedef for complex and throw together a trivial multiplication
etc macro or function.  Fortran does it better, or at least hides more
of the detail of what it does while doing it.  NOW try to invent a
quaternion in fortran.  Hmmm, not so easy.  In C it is the SAME thing
you did for the complex type.  Try inventing a generalized clifford
algebra (geometric algebra, for purists) variable of some grade.  In
fortran I expect that this would be very difficult indeed. In C it is
just the same as the complex type.

> 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.

C is much better.  C++ enthusiasts argue C++ is better still, recovering
many of fortran's advantages without C's bite-your-own-self-in-the-ass
disadvantages.

Me, after many years I've just developed one tough ass...;-)

>
>>   All of which may well be doable
>> nowadays -- did I mention that it was fortran >>IV<< that I learned?
>> Running on an IBM mainframe running MVS, JCL, HASP and all that?
>
> yes, modern FORTRANs allows user defined types, etc. (although g77 might not. 
> An old manual I have says that STRUCTURE, UNION, RECORD, and MAP are all not 
> yet implemented)  Note, all upper case, because real programmers use punched 
> cards, and neither the 026 or 029 keypunches have lower case.

Gaaah.

Or rather, GAAAAH.

>
>> Hopefully "modern" fortran is a whole lot closer to C and supports some
>> sort of struct/union or equivalent thereof, and some sort of dynamical
>> memory allocation.
>
> F77 had dynamic array allocation (you can do DIMENSION X(*))

yeah, sorta.  I never quite understood this.  How does one free it?
What about if typing, if the type is a freeform typedef'd struct?  Etc.
Of course I quit fortran before I had the chance to learn...

     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