Should I convert FORTRAN code to C?

[der Mouse]

In article <10655 at agate.BERKELEY.EDU>, jerry at violet.berkeley.edu ( Jerry Berkman ) writes:
>> [C vs FORTRAN]

> C is missing many useful intrinsics.  I have trouble taking a
> language seriously for numeric computation if the language doesn't
> even know about absolute values, e.g.:   x = abs(x);  or signed
> numbers,  e.g.  x = +5;  Both statements are illegal in C.

Not so.  The first one is perfectly legal; any compiler that won't
accept it is broken.  The second one is legal under the dpANS (or at
least in K&R V2), though it used to be illegal.  (Why do we need a
unary plus operator anyway?  I never missed it.)

> [ i = j**k   and   y = x**6 ]

How do you express link->next->chain = vec[i++]; in FORTRAN?  Why try
to create a war of features?  It sounds as though your sort of work is
better expressed in FORTRAN.  Please stick to FORTRAN, then, and stop
complaining about C.  You aren't complaining about how Snobol makes it
difficult and slow to do what you want to do, are you?

> Actually, C does not have a concept of intrinsic at all.

It does under the dpANS, or very close to it.  If we say, for example,

#include <math.h>

 x = sqrt(y);

then we are justified in believing the sqrt() routine to be the math
library routine.

> For that matter, since sqrt() is a FORTRAN intrinsics, I get an error
> message from any decent FORTRAN compiler for sqrt(integer).  None
> from C of course (running lint is a hassle).

In other words, you recognize that you have such a checking feature
available, but using it is too much trouble, so you complain about the
lack of checking.  Riiight.  (I certainly can't see the hassle in
running lint; just say "lint" instead of "cc"....)

					der Mouse

			uucp: mouse at mcgill-vision.uucp
			arpa: mouse at larry.mcrcim.mcgill.edu