From: dpbsmith@world.std.com (Daniel P. B. Smith)
Subject: Re: SPECIFIC Question about Fortran  (vs. C)
Organization: The World Public Access UNIX, Brookline, MA
Date: Sat, 2 Jan 1993 03:39:56 GMT

I don't think the FORTRAN standard addresses accuracy directly.
Both FORTRAN and C put SOME constraints on the language.
For example, the C standard requires that there be headers
named limits.h and float.h that document various properties of
the numeric environment and set minimum requirements.  

In C, for example, it is guaranteed that an int must be able
to represent the range -32767 to +32767 (i.e. it's at least sixteen
bits).  A float is guaranteed to have at least six decimal digits of
precision, a double is guaranteed to have at least ten.  I'm afraid
I don't have a handy FORTRAN reference so I can't tell you what the
equivalent is.

Generally speaking, the relevant standard for numerical precision is
probably not any of the language standards, but the ANSI/IEE standard
754 for binary floating-point arithmetic.

The difference between the languages lies not so much in what the
standard says, but in the culture that surrounds them.  Because it's
in the culture that FORTRAN is used for numerical work, you can have
a much higher degree of confidence in the accuracy, efficiency, and
correctness of the numerical libraries supplied with FORTRAN compilers
than with other languages.  Gross bugs in floating-point libraries are
by no means known; there was a famous egregious example in one of
Microsoft's BASICs for the PC; I believe 1.0/10.0 printed out as 0.01
or something like that.  

As recently as 1984, you could purchase commercial C compilers that
did not support floats at all.

In practice, if you are using FORTRAN compilers and an IEEE-754
environment (which includes current Intel coprocessors, the Apple SANE
libraries, and many minicomputers) it is very likely that the compiler
will implement reals as IEEE 32-bit and double precision as IEEE 64-bit.
If so, it is quite likely that identical FORTRAN programs will give
identical numerical results.

The culture also dictates that FORTRAN compilers are usually highly
optimized.  In fact, the ORIGINAL IBM FORTRAN was a very daring and
ambitious project because they did not believe it would succeed unless
FORTRAN-generated code was nearly as efficient as handwritten assembly
language, so it was a very tricky, highly optimized compiler.  One of
the reasons why FORTRAN historically has been somewhat ugly is that 
language features that make the language nicer to write are resisted if
they make it hard to write optimizing compilers.  

What I'm trying to say is that, suppose you need to solve some
frammistan Eigen-whoozis multi-correlate dual-elimination boundary
integrommet problem.  First of all, if you hit the libraries and the
journals, the chance of finding a ready-made solution written in 
FORTRAN is much higher than the chance of finding one in C, if for 
no other reason than that they've been publishing 'em since the fifties
in FORTRAN.  Second, if you find solutions in both FORTRAN and C, 
the chances are higher that the one in FORTRAN is correct -- because the
one written in C is probably a translation of something written in
FORTRAN in the first place.

And if you write the thing in C there's a small but nonzero probability
that you'll expose some bug in the compiler and/or libraries you're using,
because the vendor didn't think it was as important and didn't work as
hard on it as they did on, say, making sure their pointer casts did the
right thing.  And if you report it, they're more apt to respond with 
a yawn, because for every customer that complains that the computer
won't compute, there are a hundred asking about whether it will generate
DLL's, or whether it comes with a full set of Windows 3.1 headers, or
whatever.

C is the implementation language for UNIX.  Like all good languages it's
been extended and does lots of things well, but chars and ints are
structs and pointers are its reason for being, and floats are something
else it also does.  FORTRAN was designed to do floating-point numerical
calculations with efficiency comparing favorably with hand-coding.
That's ITS reason for being, most customers have that expectation
and most vendors meet that expectation.

Cheers,

--Dan Smith
-- 
Daniel P. B. Smith
dpbsmith@world.std.com
Newsgroups: comp.lang.fortran