geoff@callan.UUCP (Geoff Kuenning) (06/27/84)
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.
dgary@ecsvax.UUCP (07/09/84)
<>
This business on numerical accuracy is a VERY important point often overlooked
even by scientific programmers. A recent Scientific American had an article
that did accuracy comparisons of various machines and languages. CDC FORTRAN
was something like 8 orders of magnitude (!) better than IBM PC BASIC. The
winning calculator was a TI (this surprised me) and the runner up was an HP
followed very closely by a Sharp. The calculators were much better
than the micros tested but not as good as the CDC, which is as one
would expect. More impressive is the fact that double precision
FORTRAN was not much more accurate than single precision on the CDC,
suggesting they are doing everything in double precision (a reasonable
choice for number crunching architecture, I would imagine).
D Gary Grady
Duke University Computation Center, Durham, NC 27706
(919) 684-4146
USENET: {decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary