Should I convert FORTRAN code to C?

[Mike Percy]

>From article <10655 at agate.BERKELEY.EDU>, by jerry at violet.berkeley.edu ( Jerry Berkman ):
> 
> 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;


  x =+ 5 used to be an example of a C operator which is now x += 5. Most
compilers I've used warned me about an obsolete operator or some such. 
Just write is as x = +5 rather than x =+5 and things should be fine.

x = abs(x) is provided by virtually every math library.

> For that matter, how do you translate  y = x**6 from FORTRAN to C?

For that matter, how do you translate *p %= 2 from C to FORTRAN?

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

"Gosh Dad, why do those airline pilots have to run through that
checklist, it's such a hassle"
"Well, Beaver, if they didn't, they might miss some small detail that
could cause a crash"
"Geeee"

> 
> Also, I like the semantics of sqrt() under FORTRAN better:  on all
> FORTRAN systems I have used, if y = -1., the result is a fatal error.
> In C, it depends on what the library does.  I have used C libraries
> which returned sqrt(abs(y)), others which return 0, and 4.3 BSD on a
> VAX returns the reserved operand.
> 

Which is why you have the freedom to decide exactly what you want by
redefining the function slightly, maybe with a #define.

Also, if you like FORTRAN math stuff, why not call functions from a
FORTRAN library. NAG comes to mind. It's easy enough to do.

FORTAN does have an extreme advantage over C in one respect --
vectorizability (is that a word?) of certain things (some array
processing for example). If I remember right, this was one of the things
that noalias was supposed to help change.