Adaptive, recursive numerical integration of a function using Simpson's rule. INTEGRAL.C Source in C for integration routine INTEGRAL.PAS Source in Pascal for integration routine INTEGRAL.DCL Declaration of integral for calling Pascal program TSTINTEG.C Source in C for example of use of integral TSTINTEG.PAS Source in Pascal exanoke for use of of integral The routine integral is a very powerful numerical integrator which adapts to the function being integrated to determine where small steps should be taken and economize on the number of times the function is called. The example given integrates the function 1/sqrt(x) from -9 to 1.0e4, showing that the integrator can even handle singular but integrable functions. The correct answer is 206. Additional documentation is contained in the source files. A word of caution: without an 8087 co-processor the test case on integral should not be run beyond eps = 1.0e-7 or the execution time will severely try your patience. The test case given takes a couple of minutes. Beyond 1.0e-5 the results are meaningless without double precision. Be aware that PC-DOS does not know how to stop a compute bound program until it does some I/O, so stopping this program may be more easily done by a boot (ugh). Integration of a system of ordinary differential equations using the Runge-Kutta-Fehlberg method. RKF45.C Source in C for RKF45 integrator RKF45.PAS Source in Pascal for RKF45 integrator RKF45.DCL Declaration of RKF45 for calling Pascal program TSTRKF45.C Source in C for example of use of RKF45 TSTRKF45.PAS Source in Pascal for example of use of RKF45 RKF45 uses the 4-th order 5 stage Runge-Kutta-Fehlberg method to integrate a system of ordinary equations. The example shows the integration of the simple second order differential equation of an oscillator to give the cosine function. The exact answer is cos(20 pi) = 1.0 and the derivative = 0. The example further shows how to make use of the ability of the integrator to adapt to the equations being integrated to maximize the efficiency. Additional documentation is contained in the source files. Text formatting program, from PC-Sig diskette 50 has been slightly modified to conform to Kernighan and Ritchie C. ROFF.H0 Header common to all roff source ROFF.H1 Header specific to roff1 ROFF.H2 Header specific to roff2 ROFF1.C Part 1 of roff source ROFF2.C Part 2 of roff source ROFF3.C Part 3 of roff source ROFF.DOC Documentation of roff This version of ROFF was obtained from PC-Sig on their disk #50. While this is a working program, the version offered on PC-Sig disks #130 - 132 called fmt in Pascal offer a more useful package, providing more functions. So long as C source is not required, it is recommended to use the #130 - 132 version. One disadvantage of the Pascal version is that the executable module produced by the IBM PC-Pascal compiler is 40 kBytes compared to the C version's 22 kBytes. The DOS executable version on disk #50 works as advertized, except for underlining (see bugs below), but the C source is non standard, and will not compile on the Quantum C compiler without complaints. The problems were fixed by the changes listed below. 1. Removed spurious reference to "struct _iobuf *bufr", which seems to be a relic of the BDS compiler, and replaced the statement with the standard construct "FILE *fopen(), *bufr". 2. Separated roff.h and roff.he into independent parts called roff.h0, roff.h1, and roff.h2 to avoid duplicate entries. The duplicates in roff.h and roff.he were very dangerous, because one had to be sure that changes in defaults happened in both places. 3. Changed the defaults for the line length to 72 and margins 1-4 to 3. 4. Deleted references to ctype.h; seems to be a characteristic of the BDS C compiler. 5. Changed references to "stdio.h" to to conform to K & R standard, and get the standard library file rather than looking in the current directory. 6. Changed the name of the definition FILE to FILE_RO to avoid conflict with the C standard FILE definition. 7. Changed reference to stcd_i to atoi to conform to K & R. 8. Changed reference to fgets to fgetline because the original source assumed that \n is placed at the end of the string, in conflict with the K & R standard. (By the way, this subtle confusion was difficult to track down.) The function fgetline is a Quantum C compiler function which does what the author of the program intended; it is not a documented function in K & R, but is the analog of getline on an arbitrary file. 9. Consolidated the old file "FILEIO.C" along with some extra small procedures into ROFF3.C so that all ROFF related files begin with the letters "ROFF". (For compatibility reasons source for fgetline, abs, min, and max have been added to ROFF3.C.) There are a few bugs/features to catch the unwary: A line to be centered may not begin with a tab or a space. The underline function depends upon a backspace and overstrike working; this not the case with the IBM printer nor the IBM monitor. The underline sets the 8-th bit, meaning that all the special characters are unavailable. Paragraph indententing is a bit delicate; it is most easily done by a blank line followed by a .ti n command. The subsequent text may not begin with a TAB or one or more blanks if the formatting commands are to be unconditionally obeyed; leading spaces and TABs are taken as absolute spacing. This has the undesirable effect that a piece of text typed to have proper indenting on the screen may not be put into ROFF format by simply inserting some ROFF commands. TABs are hard-wired at every 8-th column, so in a special case one may indent paragraphs by setting the right margin at 5 so that a paragraph beginning with a tab will look like it is indented by 3 spaces. The TABs and leading spaces are taken literally so that tables are correctly printed (albeit ignoring the right margin command) without any further formatting, so this "bug" may be considered a "feature". All C source on this diskette has been successfully compiled using the Quantum C compiler under the QNX operating system and the CI-C86 compiler under PC-DOS 1.1. It is believed that the source conforms to K & R standard C. All Pascal source has been successfully compiled with the IBM PC-Pascal compiler version 1.0, and the IBM Pascal/VS compiler for the 3081 mainframe. Neither integral nor rkf45 will work with Turbo Pascal version 1.0 because Turbo does not allow passing functions as arguments to functions. There are some peculariaties in both the C and Pascal source for the integrator to handle some bugs found in the respective compilers. Appropriate comments document these areas. Harvey L. Lynch (408) 737-0164