Xref: utzoo comp.lang.fortran:4172 comp.lang.c:34302
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!convex.csd.uwm.edu!tong
From: tong@convex.csd.uwm.edu (Shuk Y Tong)
Newsgroups: comp.lang.fortran,comp.lang.c
Subject: Re: Fortran vs. C for numerical work (SUMMARY)
Message-ID: <7928@uwm.edu>
Date: 28 Nov 90 20:21:25 GMT
References: <9458:Nov2721:51:5590@kramden.acf.nyu.edu> <7097@lanl.gov> <17680:Nov2806:04:1090@kramden.acf.nyu.edu>
Sender: news@uwm.edu
Followup-To: comp.lang.fortran
Organization: University of Wisconsin - Milwaukee
Lines: 57

In article <17680:Nov2806:04:1090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <7097@lanl.gov> ttw@lanl.gov (Tony Warnock) writes:
>> >I agree that this is a problem. However, the double-pointer solution
>> >a[i][j] for *(*(a + i) + j), all within current C. It is extremely
>> > difficult to do in Fortran.

>>     Fortran has allowed
>>     one to write a(i,j,k,l,m,n,p) for years.
>
>Huh? A double-pointer array, as we were discussing, is a
>single-dimensional array of pointers to single-dimensional arrays. To
>access a random element of the array takes two additions and two memory
>references. In contrast, to access a random element of a flat array
>takes two additions, a multiplication, and a memory reference. On most
>widely used machines, a multiplication is quite a bit slower than a
>memory reference, particularly a cached memory reference. That's why
>double-pointer arrays are better than flat arrays for so many
>applications.
>
>Fortran can't deal with a double-pointer array efficiently because it
>doesn't have pointers. Simulating pointers efficiently is what I was
>calling difficult. Do you disagree?

Yes. First of all, arrays are the most common data structure in
scientific computing. By not providing a generic array type in C(i.e.,
one which can have a variable in its declaration in functions),
it basically says C is not for numerical work. As for
two-dim arrays, in C, it has to be simulated by a pointer array
which is clumsy (it becomes clumsier for 6-dim arrays) and 
runs much SLOWER on vector machines. The reason
is simply the compiler is unable to tell where each element a[i][j]
points to. It might be posible to put tons of directives to tell
the compiler what is going on, but why bother when you can do
it by using a(i,j) alone ? As to accessing a random element a(i,j),
it is true that that a(i,j) is slower than a[i][j], but
the point is that in scientific programing, accessing a
random element in a ramdom place is RARE. Even it is
not rare, it doesn't matter becuase the CPU hog in scientifc 
computing is LOOPS with ARRAYS in it. When a(i,j) is within a loop, 
its address usually can be gotten by an addition (a constant stride 
or an increment, depending on which index runs faster).

Before ANSI C compiler became widely available, it was a nightmare
to do numerical work in C: arbitary evaluation order, mindless
promotion, too many to name. ANSI C is much better in this regard,
but still not quite has the (numerical) capbilities of Fortran.
Some of the common functions, like sqrt etc., is generated inline
by a Fortran compiler, but no way of doing it in C. If complex
math is desired, there is no end of trouble in C. A few dosens of
functions (the compiler better has inline capability, which is not
true present for most compilers) or macros need to be written.
I am almost sure people like to write c=c1/c2, c=r/c1,
rather than CDIV(c,c1,c2), RCDIV(c,r,c1).

The only possibe candidate of the languages that can replace
Fortran is C++ ( I doubt that too ), but not C, because C itself
will be dead when a true C++ compiler is written.