Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site callan.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!zehntel!tektronix!hplabs!sdcrdcf!trwrb!scgvaxd!wlbr!callan!geoff
From: geoff@callan.UUCP (Geoff Kuenning)
Newsgroups: net.lang
Subject: FORTRAN vs. C:  the REAL reason FORTRAN is still alive
Message-ID: <174@callan.UUCP>
Date: Wed, 27-Jun-84 04:06:45 EDT
Article-I.D.: callan.174
Posted: Wed Jun 27 04:06:45 1984
Date-Received: Tue, 3-Jul-84 02:32:33 EDT
Organization: Callan Data Systems, Westlake Village, CA
Lines: 48

All of this discussion of the merits of Fortran vs. C seems to be missing one
of the most important points of all:  ACCURACY.  This is not a feature that is
inherent in either language, of course, but the fact of the matter is that a
Fortran square-root routine (or almost any other library function) is usually
both faster and more accurate than the corresponding C routine.  The reason is
simple:  since Fortran is widely used for numerical processing, the
manufacturers have a very strong incentive to produce the best libraries
possible.  C, by contrast, was written by a (brilliant) Bell Labs researcher
who was not a specialist in numerical mathematics.  To make matters worse,
most C libraries available to the world were derived from the PDP-11 library
by a compiler or OS specialist who did not understand at all what the effect
of a change oin floating-point format would be on a given algorithm.

If you are not familiar with the inherent flakiness of all floating point, try
a couple of experiments with your favorite compiler.  I suggest assigning a
constant (e.g., pi) to a variable, reading the same constant into another
variable with formatted I/O, and then printing both variables.  A really bad
compiler will print values that differ from each other and from the values you
originally typed (this is after allowing for the precision limitations of the
floating-point representation, of course;  nobody expects the machine to be
able to retain the 50th significant digit).  Another interesting experiment is
to find out how many times you can do sqrt(sqrt(sqrt(...(2)))) and still be
able to get 2 back by repeatedly squaring it.  Some of the other reversible
operations (notably exp/log) are even more vulnerable to this test.  As a final
test, try a fairly complex iterative calculation (e.g., Gaussian elimination or
Runge-Kutta) and compare the results to what your HP calculator tells you.  (HP
employs beaucoup numerical mathematicians;  many library writers use an HP to
check the quality of their routines).  If you want more examples, mail me and I
will send you some;  I even have a function squirreled away that cannot be
solved for x=0 to within plus or minus 0.5!  (The correct root is something like
1.6, but even a 14-digit HP calculator can't solve it).

My point is not that C is inherently inaccurate;  there is no reason a good
compiler can't be done.  But most C implementations were done by people who
were basically researchers, and they simply didn't have the resources to spend
two person-years writing the best possible library.  I would count on the
people at Cray to do the best job possible;  after all, it's their bread and
butter.  Bell Labs and Berkeley I wouldn't trust very much.
Array-processor companies like Floating Point Systems and Sky Computer
tend to produce stuff that is as trustworthy as Cray's, simply because nothing
is quite so embarrassing as selling a number-crunching machine that squashes
the results.

I hope I haven't come across as a snooty know-it-all.  The fact is that I am
aware of these problems precisely because I learned the hard way that I *don't*
know a damned thing about numerical mathematics.  No apology--it's not even
close to my specialty and nobody can follow everything.  When I need to do
real math, I find me an expert.