Fortran vs. C for numerical work

[Henry Spencer]

In article <1990Nov22.051446.1871 at ccu.umanitoba.ca> salomon at ccu.umanitoba.ca (Dan Salomon) writes:
>    ...Even the fundamental
>    operation of reading input is tricky in C, as shown by the recent
>    postings on scanf, gets, and fgets.

Actually, Fortran has much the same problems in this area:  the facilities
for formatted input make little provision for clean error recovery.  This
doesn't show up very much because the stereotypical use of Fortran is for
batch jobs, not interaction.

> 2) FORTRAN is dangerous to use, but not as dangerous as C.  For
>    instance, most FORTRAN compilers have subscript checking as an
>    option, while I have never encountered a C compiler with this
>    feature.  The ANSI standard for function prototypes will
>    give C an edge over FORTRAN in parameter mismatch errors, but
>    that improvement is relatively recent and not enforced yet.

One might ask what compilers you are using.  C compilers have trouble doing
subscript checking because of the complexity of C pointers, but debugging
compilers/interpreters which do this checking *do* exist.  And there are
already many C compilers which implement prototypes.

> 3) There is a large body of well tested mathematical packages available
>    for FORTRAN, that are not yet available in C.  For example the
>    IMSL package.  However, this situation is improving for C.

As others have mentioned, given f2c, this is a non-issue.  They are all
available in C now.  (Sometimes they run faster that way, too...!)

> 4) FORTRAN still gives the option of using single precision floating
>    calculations for speed and space optimizations, whereas C forces
>    some calculations into double precision.

Not any more.
-- 
"I'm not sure it's possible            | Henry Spencer at U of Toronto Zoology
to explain how X works."               |  henry at zoo.toronto.edu   utzoo!henry