Xref: utzoo comp.lang.fortran:735 comp.lang.c:10670 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!helios.ee.lbl.gov!pasteur!agate!violet.berkeley.edu!jerry From: jerry@violet.berkeley.edu ( Jerry Berkman ) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Should I convert FORTRAN code to C? Keywords: language conversions, FORTRAN, c Message-ID: <10655@agate.BERKELEY.EDU> Date: 8 Jun 88 01:17:00 GMT References: <2742@utastro.UUCP> <20008@beta.UUCP> Sender: usenet@agate.BERKELEY.EDU Organization: University of California, Berkeley Lines: 60 In article <20008@beta.UUCP> jlg@beta.UUCP (Jim Giles) writes: >In article <2742@utastro.UUCP>, rlr@utastro.UUCP (Randy Ricklefs) writes: >> We will soon start porting software from a number of different sources to a >> micro-processor-based UNIX system. Most of the code is in various dialects >> of FORTRAN. The question that arises is whether to convert all this stuff >> to a more modern language, particularly c. >> 3) Is c a suitable replacement for FORTRAN in terms of mathematical capabil- >> ities and portablility? 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. And what about: i = j**k In C this becomes: i = pow( (double)j, (double)k); For that matter, how do you translate y = x**6 from FORTRAN to C? Most FORTRAN compilers will optimize this using only 3 multiplies. If you translate it to C as y = x*x*x*x*x*x, then there is a chance the compiler will do as well as FORTRAN, but I wouldn't bet on it. And if you use the translation y = pow(X,5.0), you have an out-of-line procedure call plus an expensive evaluation. Actually, C does not have a concept of intrinsic at all. In the FORTRAN statement: x = sqrt(y) you are guaranteed by the standard that the square root intrinsic is invoked (unless there is an external statement). By contrast, the C statement: x = sqrt(y); does not guarantee anything of the kind. A user defined function could be called, or "sqrt" could be a define. For sqrt(), this is not usually a problem. But I'd be a lot less sure of other names like acos or sinh. 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). 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. >On UNIX and UNIX-like systems, the Fortran support library is written >almost entirely in C. The 4.3 BSD math libraries for the VAX are written mostly in assembler. That the 4.3 BSD VAX FORTRAN I/O library is written in C using standard I/O may be why it is so slow. The VAX math library is about as fast as the VAX VMS math library while the BSD I/O library is up to 3 or 4 times as slow as the VAX VMS I/O library. Much of the Cray UNICOS math and I/O support libraries are written in assembler. - Jerry Berkman Central Computing Services, U.C. Berkeley jerry@violet.berkeley.edu