Numerical Recipes - BSD UNIX FILES: This the main directory of a distribution of Numerical Recipes software. You may have distributions for C recipes, Fortran recipes, or both, depending on what you have purchased. Each directory for a language contains some subdirectories which hold various files. The list is: recipes_{f or c-ansi or c-kr} Main directory containing recipe files for a particular language. recipes_f is for Fortran recipes_c-ansi is for ANSI C recipes_c-kr is for KR C recipes_{f or c-ansi or c-kr}/bin Empty directory, eventually may contain some program binaries. recipes_{f or c-ansi or c-kr}/doc Numerical Recipes documentation. recipes_{f or c-ansi or c-kr}/misc Miscellaneous additions for special cases or environments. recipes_{f or c-ansi or c-kr}/recipes Source for all the subroutines in "Numerical Recipes" for that language, as well as a slave makefile to create a library of recipes. recipes_{c-ansi or c-kr}/include Include files recipes_{f or c-ansi or c-kr}/demo Subdirectory containing demonstration files for a particular language. recipes_{f or c-ansi or c-kr}/demo/answers The "correct" results for comparison with the test output. recipes_{f or c-ansi or c-kr}/demo/bin An empty directory, where the compiled demos can be stored. recipes_{f or c-ansi or c-kr}/demo/data Data files required to run some of the examples. recipes_{f or c-ansi or c-kr}/demo/responses The responses to run the examples non-interactively. recipes_{f or c-ansi or c-kr}/demo/results Contains makefile for running all the demos and will store the output of the tests. recipes_{f or c-ansi or c-kr}/demo/src Source for all the example programs given in the "Example Book" for that language. INSTALLATION: The installation procedure is essentially the same for all cases. All but the first two steps are optional. Overview: In the ideal case, the entire process is controlled exclusively from a top-level makefile in one of the distributions. If you have more than one distribution, you need only work from the top makefile for one of them. A common environment is defined in it, and then passed to subsidiary makefiles. If there are no system-specific problems, this should be the only makefile that requires editing. It automatically determines which distributions (Fortran or C) are present, and then attempts to execute subsidiary make's for all of them (this can be changed just by editing the targets in the primary makefile). There are three secondary makefiles that may be called - one to compile recipe files and put them into a library (and install it), possibly one to create binaries of the demonstration programs (though these take up much disk space), and one to generate results from running these programs. If problems occur, some of these makefiles may require editing. NOTE THE COMMENT IN THE RECIPES MAKEFILE REGARDING SPECIAL CASES FOR RECIPES AFFECTED BY COMPILING OR OPTIMIZING BUGS. Walk-through: In detail, the installation steps are: 1) Edit the main makefile, in this directory (top level). Set the various parameters to be appropriate to your system. You may want to review your compiler's manual, and the document COMPILING, for use information. 2) Type make. By default, this will create the library file(s) and install them in the directory specified as LIBDIR in the master makefile. There should be several megabytes of space free for each distribution, to hold all the .o (object) and .a (library) files that will be created. This process may take some time (order-of-magnitude an hour), so you may wish to run it in the background and capture the results in a file: Users of sh: make > make.log 2>&1 & Users of csh: make >& make.log & On most systems, you can check the progress of the make by running tail -f make.log This step also creates the programs badluk, fredex, sfroid, sphfpt and sphoot. You may need to become "root" or assume super-user privileges to write to the directory where the library is to be placed. The installation step can be done independently, as make install . 3) The command make clean will remove all the residue .o files and the uninstalled .a files. It may be a good idea to delay this until after testing. 4) Demo program binaries can be created by make demobins . You may not want to create these files, as they take up a great deal of disk space. 5) Typing make results will run the demos and place the output in the results directory mentioned earlier. If the demo binaries have been created in the step above, they will be used. If not, the binaries will be compiled as needed, then deleted if they are run successfully. This scheme is intended to save disk space. Binaries which fail to run properly will not be deleted. Note that there are some assumptions about the relative positions of various directories built into this process. Users of sh: make results > test.log 2>&1 & Users of csh: make results >& test.log & Many of the demos are interactive, but the test process uses a file of responses, contained in the responses subdirectory. In some cases, a demo program may become blocked because it requires input but none is provided from the response file. This happens when an unexpected execution path is taken, usually due to a difference in machine precision. Try compiling the demo program and running it in the foreground with no I/O redirections. You may have to check over the source for the demo program and for the routine it demonstrates in order to find the cause. Note that when compiling, error information on the process itself is saved in the log file which collects the output of the "make". This information ordinarily does NOT go into the "results" files. Often the messages are just benign warning or suggestions from the compiler, but it's worth going through the output to check for a serious or significant problem. 6) Check the results. See if there are any error messages in test.log. If not, go ahead and compare the results now in the directory called results, to the correct results provided in the directory called answers. It may be possible to just run diff(1) on the two directories: diff [-s] results answers > diff.log However, your Fortran may format some answers differently than ours, such as 0.0 verses 0.0000. This, plus differences due to rounding, may cause the results from diff(1) to be less helpful. If you have the PERL language on your system, you may find the "nrdiff.pl" approximate-comparison program (in the results subdirectory) useful.