Numerical recipes

1.2 Some C Conventions for Scientific Computing 25
is immediately thrown away. A corollary of these rules is that all the real-number
standard C library functions are of type double and compute to double precision.
The justification for these conversion rules is, “well, there’s nothing wrong with
a little extra precision,” and “this way the libraries need only one version of each
function.” One does not need much experience in scientific computing to recognize
that the implicit conversion rules are, in fact, sheer madness! In effect, they make it
impossible to write efficient numerical programs. One of the cultural barriers that
separates computer scientists from “regular” scientists and engineers is a differing
point of view on whether a 30% or 50% loss of speed is worth worrying about. In
many real-time or state-of-the-art scientific applications, such a loss is catastrophic.
The practical scientist is trying to solve tomorrow’s problem with yesterday’s
computer; the computer scientist, we think, often has it the other way around.
The ANSI C standard happily does not allow implicit conversion for arithmetic
operations, but it does require it for function arguments, unless the function is fully
prototyped by an ANSI declaration as described earlier in this section. That is
another reason for our being rigorous about using the ANSI prototype mechanism,
and a good reason for you to use an ANSI-compatible compiler.
Some older C compilers do provide an optional compilation mode in which
the implicit conversion of float to double is suppressed. Use this if you can.
In this book, when we write float, we mean float; when we write double,
we mean double, i.e., there is a good algorithmic reason for having higher
precision. Our routines all can tolerate the traditional implicit conversion rules,
but they are more efficient without them. Of course, if your application actually
requires double precision, you can change our declarations from float to double
without difficulty. (The brute force approach is to add a preprocessor statement
#define float double !)
A Few Wrinkles
We like to keep code compact, avoiding unnecessary spaces unless they add
immediate clarity. We usually don’t put space around the assignment operator “=”.
Through a quirk of history, however, some C compilers recognize the (nonexistent)
operator “=-” as being equivalent to the subtractive assignment operator “-=”, and
“=*” as being the same as the multiplicative assignment operator “*=”. That is why
you will see us write y= -10.0; or y=(-10.0);, and y= *a; or y=(*a);.
We have the same viewpoint regarding unnecessary parentheses. You can’t write
(or read) C effectively unless you memorize its operator precedence and associativity
rules. Please study the accompanying table while you brush your teeth every night.
We never use the register storage class specifier. Good optimizing compilers
are quite sophisticated in making their own decisions about what to keep in registers,
and the best choices are sometimes rather counter-intuitive.
Different compilers use different methods of distinguishing between defining
and referencing declarations of the same external name in several files. We follow
the most common scheme, which is also the ANSI standard. The storage class
extern is explicitly included on all referencing top-level declarations. The storage
class is omitted from the single defining declaration for each external variable. We
have commented these declarations, so that if your compiler uses a different scheme
you can change the code. The various schemes are discussed in §4.8 of [1].
Sample page from NUMERICAL RECIPES IN C: THE ART OF SCIENTIFIC COMPUTING (ISBN 0-521-43108-5)
Copyright (C) 1988-1992 by Cambridge University Press. Programs Copyright (C) 1988-1992 by Numerical Recipes Software.
Permission is granted for internet users to make one paper copy for their own personal use. Further reproduction, or any copying of machinereadable
files (including this one) to any server computer, is strictly prohibited. To order Numerical Recipes books or CDROMs, visit website
http://www.nr.com or call 1-800-872-7423 (North America only), or send email to directcustserv@cambridge.org (outside North America).