Solution:
Please recognize that we get hundreds of reports like this, and that
they are user typing errors virtually 100% of the time! This is true
no matter how carefully the user proofreads, or says they do. For
example, if
you mistake an "ell" for a "one" or an "oh" for a "zero", you'll probably
make the same mistake when you proofread, or when you retype the program.
Users always overestimate the accuracy of their typing. This
means you!
The solution is to obtain the routines in machine readable form, by purchasing the appropriate diskette, CDROM, or on-line download from the Numerical Recipes On-Line Store.
Solution:
No, there are not bugs in these routines. By now they have
been thoroughly tested by many thousands of users over many years.
For C users, a common problem is attempting to use the routines with arrays declared using native C declarations, rather than using the required Numerical Recipes allocation utilities. This is discussed in the book, pp. 18-23.
For both C and Fortran users, the other common problem is not reading the book carefully, to understand how the input and output arrays are packed. The Fourier routines are particularly tricky and unforgiving on this.
Here is the tail end of the 'make' output:
cc -I../include -c rkck.c
cc -I../include -c rkdumb.c
cc -I../include -c rkqs.c
cc -I../include -c rlft3.c
cc -I../include -c rofunc.c
/usr/lib/cmplrs/cc/cfe: Error: rofunc.c, line 11: redeclaration
of 'select'; previous declaration at line 158 in file
'/usr/include/sys/select.h'
float select(unsigned long k, unsigned long n, float arr[]);
------^
/usr/lib/cmplrs/cc/cfe: Error: rofunc.c, line 11: Incompatible function
return type for this function
float select(unsigned long k, unsigned long n, float arr[]);
------------^
*** Exit 1
Stop.
*** Exit 1
Stop.
The Solution:Some operating systems have a problem in that the system include files contain more information than is expected. This leads to a conflict between the declarations for the system version of select() and the Numerical Recipes function of the same name. If you're not planning on using the Numerical Recipes routine select(), the simplest fix is to remove (or rename) its declaration in the file nr.h, and not to reference it anywhere else.
Another solution is to add the option -D_ANSI_C_SOURCE to the compile flags. This option will generally suppress the additional information in the include files, thus fixing the problem.
A file consisting only of the following two lines will suffice to test for the problem:
#include <math.h> float select();
Solution:
This problem can only occur in older Numerical Recipes releases, or
if you are trying to use the PC version on a UNIX machine (bad!).
In newer releases, the NR function "erf" was renamed to "erff",
and "erfc" was renamed to "erffc" to avoid this UNIX namespace conflict.
For a workaround, first try compiling with either -D_POSIX_SOURCE or -D_ANSI_C_SOURCE . If this doesn't work, then do the above renaming of the NR routines in the files nr.h, erf.c, and erfc.c . Better yet, get the free upgrade for your UNIX Numerical Recipes release.
Solution:
Some Fortran versions have an ichar() function that returns
values in the range [-128,127] instead of [0,255]. Replace the ichar()
functions with iichar(), found in recipes_f/misc/bits.f of the
Numerical Recipes UNIX release as installed.
Solution:
The system 'cc' compiler has a bug which causes it to generate
incorrect code in some cases involving variables with 'unsigned' as part
of their types. If you see garbage in the output of xspear, try removing
the 'unsigned' from the "j=1,ji,jt" line of crank.c. If 'xfasper' fails
with a floating-point exception, remove the 'unsigned' from the
declaration in xfasper.c .
#include < stdio.h >
main() {
int n = 10;
n = n + ((int) (-0.99));
printf("%d\n",n);
n = 10;
n += ((int) (-0.99));
printf("%d\n",n);
}
This will produce output of 10 and 9, instead of the expected 10 10.
Solution:
You'll have to get an updated compiler version.
Solution:
Check if the type long has a length of 32 bits
on the machine. This will not be the case on certain large-word machines,
such as the DEC ALPHA. Change the type in the code to one that is
exactly 32 bits. Or use the alternate version "psdes64.c", present
in the "misc" subdirectory of the Unix distribution.
Solution:
This occurs in some versions of DIGITAL Visual
Fortran, the successor compiler to Microsoft Fortran PowerStation.
The solution is to add "/link /stack:8000000" AFTER everything else on
the compiler command line (after all .obj files, not just options), or
make the equivalent stack size change in the IDDE settings. You might
not need this big a value, but we know that this one works.
Solution:
This occurs because the default integer kinds
in CF90 are rather different from those of virtually all other machines.
A patch file is available here that (we
think) fixes all such problems. Let us know if any others are encountered!
Solution:
In this compiler version, Microsoft suddenly
decided to turn an innocuous warning into a fatal compilation error.
The NR code is semantically correct, since the path that "doesn't return
a value" actually calls the error routine, from which there is no return
anyway. The workaround is to add a return statement after the call
to the error routine.
Solution:
These figures were not available in a format compatible
with the downloadable PostScript and Acrobat files, and were thus
regretfully omitted from the free downloadable version. One solution
is to go to the library and photocopy just the missing two figures.
Another solution, which we like better, is for you to buy the book!
Solution:
Actually this paper has been obsoleted by
work of Cohen, A., Daubechies, I, and Vial, P., "Wavelets on the
Interval and Fast Wavelet Transforms", Applied and Computational
Harmonic Analysis, 1, 54-81 (1993). But if you really want the first
reference, it finally appeared as: M.H. Freedman and W.H. Press,
``Truncation of Wavelet Matrices: Edge Effects and the Reduction of
Topological Control,'' J. Linear Algebra and Applications,
234, 1 (1996).