Should I convert FORTRAN code to C?

[Leo de Wit]

In article <20340 at beta.lanl.gov> jlg at beta.lanl.gov (Jim Giles) writes:
>In article <224 at raunvis.UUCP>, kjartan at raunvis.UUCP (Kjartan Pierre Emilsson Jardedlisfraedi) writes:
>>   Now here there seems to be a little misunderstanding.  I have never
>> understood why Fortran users keep saying that array indexing is awkward
>> in C.
>> [...]
>
>Awkward isn't the problem.  I don't like the double bracket notation,
>but anyone can write a macro to turn ARRAY(i,j,k) into array[i][j][k].

Matter of style. I don't like seeing an identifier that could be both
an array and a function call (oh yeah, Fortran uses CALL in front of it 8-).

>The Problem is that 2-d arrays are not optimizable because they are
>immediately turned into pointer-to-pointer-to-data type of constructs.

Depends on how you implement them.

>
>>   If the array had been initialized with Create2DArray() then indexing
>> would be just as normal,i.e:
>> 
>> 		DoSomething(array,m,n)
>> 		double **array;
>> 		int m,n;
>> 		{
>> 		...
>> 		array[ i+k ][ j-i ]= 1.0;
>> 		...
>> 		}
>
>If your use of array here is in a loop (that might otherwise be vector-
>izable), the C compiler can't vectorize it because a pointer-to-pointer
   [stuff about vectorizing deleted]...

So I suggest another alternative for Create2DArray():
double **Create2DArray(w,h)
int w,h;
{
    double **r, **a;

    for (a = calloc(w * h, sizeof(**r)), r = calloc(h,sizeof(*r));
         --h >= 0;
         r[h] = a + w * h;
    return r;
}

This has two advantages: only 2 calls to calloc needed (while the
original needed h + 1), and furthermore the data itself is contiguous
in memory (pointed to by r[0]). Furthermore you can have both the speed
of vectored arrays and flat ones (whatever is more appropriate).
Another remark: perhaps it's better to replace the second calloc by a
malloc, since the contents of r[h] is changed anyway. And you can
combine the two allocations into one, as The Walking Lint pointed out.
If you're out for speed, use flat arrays and pointers into these.

>
>> [...]
>> 	       ii) You can define your own data structures, which can be any
>> 		   combination of system defined structures and user defined
>> 		   structures, array of structures, self-referential
>>                  structures and so on. [...]
>
>This capability is NOT an adequate replacement for the complex data type.
>Complex is more than just a pair of reals, there are several operations
>defined on complex (like plus) which should work naturally.  No use of
>C programming constructs can do this:
>
>      COMPLEX CVAR
>      REAL RVAR
>      INTEGER IVAR
>      ...
>      CVAR=(CVAR+RVAR)*IVAR
>      ...
>The operations (including the mixed-mode type conversions) are all done
>IN-LINE and efficiently.  C provides no way to even do this calculation
>without function calls.

This is simply not true. Even if the C compiler cannot generate inline code
it is perfectly possible to use macro's to achieve the speed that FORTRAN
boasts of (and I think even more than that). For instance:

typedef struct {
   double c_re, c_im;
} complex;

#define C_MULT(p,q,r) \
    ((r).c_re = ((p).c_re + (q).c_re, (r).c_im = (p).c_im + (q).c_im)

    complex z1, z2, result;

    /* ------- */

    C_MULT(z1,z2,result);

You can have even macro's for functions on complex numbers, and even
the best Fortran compiler cannot forsee to implement all user functions
inline (in fact I think only a very limited number of functions are
supported).  The only drawback of the macro approach is that most
people don't like the splitting up of expressions into these elementary
ones (if C had structure assignment and runtime declarators also this
problem was solved).

But I think Fortran would get into trouble if you had to work with
quaternion calculations, e.g. Nice as it is to have predefined types
and operations, it is even nicer to support creating you own types.
What if you want to describe distributions in your data model? C offers
a much cleaner approach. Pure number crunching: ok, Fortran. But
compiler building? Databases? Operating systems? Juicy, juicy (You see:
use C ;-). If I want speed, I'd better have no Fortranquilizers 8-).

   Leo.