The files needed to use PolySA as described are in PolySA.zip. This archive is constructed by bpolysa.bat using the files in zipit.txt.
The calling code is nlfitMP.vfproj. This differs from ..\nlfit.vfproj in that the poly call is replaced by a system call to PolySA. A stand alone Poly allows the Poly routine to be compiled by a different compiler than the main routine. In particular, this allows a windows user to compile the Poly section of nlfit with watcom (polysa.wpj PolySA.zip ), but to use the I-10 version of intel in the minimization. This allows the ‘DOUB’, ‘QUAD’ option which would otherwise be unavailable to watcom users. It also allows Poly to be coded in C or Pascal (PolySA.DPR). Pascal has an extended precision ‘EXPR’ option that is intermediate between double and quadruple precision. It is used here to improve the accuracy of the efficiency approximation.
Linux and Unix are open source based. This means that the form of the executable is not constant between platforms. They contain make files to allow easy re-compilation which are included in the stand alone version ..\Welcome.doc .htm. Unless Intel’s fortran is on the machine, it cannot be used – downloading an executable will almost certainly cause problems. If it is available, re-compiling with a different Poly is easy. Mixing Fortran and C requires producing an object for the C code (with a slightly different name (..\..\..\Progdet\Mixing FORTRAN and C.htm) and replacing the corresponding fortran file in the makefile with the C object file. The routine polysub.for in this case calls poly before writing unformatted files. This removes the #Unformatted issue, since the same code makes and reads these files.
PFA is
(1.1)
The PolySA code is different for each approximating function. It reads the values of xi and writes the values of fA and PFA for use by NlFitSub (..\NlfitSub\Welcome.htm) which repeatedly initiates it to find the values of fA and PFA in the minimization of
The calling code is presumed to have made the text file
1. Nlfit.tmp -- not in ..\nlfit.vfproj
READ(1,*)NV,NVMIN,ND,NDAT,NPOW,CPOL,CMIN
READ(1,’E24.16,2X,L1)’)(CONS(I),VARY(I),I=1,NV)
NV is the total number of parameters (the dimension of c).
NVMIN Is the number of parameters that are allowed to vary.
ND is the dimension of x in (1.2).
NDAT is the number of data points.
NPOW determines the relative importance of contributors to c2.
CPOL (CHARACTER*4 ‘DOUB’, ‘QUAD’, or ‘MULT’) determines the
precision expected from the polynomial.
In addition the calling code has made the unformatted file
2. xdat.tmp contains the values of (fi,ei) that appear in (1.2) -- unit 11
The PolySA code returns the unformatted file
3. fapfa.tmp (xi) each entry contains ND terms where ND is the dimension of x in -- unit 10
Experiments are described in Unformatted file sizes.doc. The basic notion is that of an integer leading term and an integer following term that gives the number of bytes Nbytes in the middle of the file. If N is larger than the size of a 4 byte integer, I-10 states, the data spans multiple blocks. It appears that gfortran and g77 do the same. Watcom starts the spanning much earlier (at 129). Watcom, however, allows the open to include recordtype=’FIXED’. This makes the input file 11 into a “binary file” with no extra Fortran information. This information is read and ignored from the input and inserted into the output file in PolySAW.for. A C version of the code will need to do the same.
The IDE’s are
1. nlfitMP.vfproj – The nlfit code modified to use a system call to polysa.exe
2. PolySA.vfproj – An intel version of PolySA used for testing – if you can compile this, I recommend changing the poly in ..\nlfit.vfproj and re-linking the entire code.
3. polysa.wpj Contains calls to Poly (double precision PFA) and to PolyM (multiple precision PFA)
4. PolySA.DPR Pascal Version. – needs the dpr and upoly. Both are in #zip of files
5. checkder.wpj – numerically checks ∂fA/∂ck
Sample calling codes are described in ..\NlfitCP Welcome.htm
1. poly.for Q M simple polynomials in real*8, real*16, and multiple precision.
2. exppoly.for FA is exponential of a simply polynomial.
3. ExpLn.for Q M
Most appropriate for functions with an extremely large positive definite
range. ..\..\..\MultiplePrecision\Bob\Welcome.htm
4. fpoly.for FA is a generalized Fermi function. Analytical derivatives. FermiFit\Generalized Fermi Function.doc .htm
5. fndpoly.for FA is a generalized Fermi function. Numerical derivatives.
6. dfpoly.for FA is the derivative of a generalized Fermi function. Analytical derivatives. Uses Bexp found in Progdet\SysRoutines\Anov.for
7. dfndpoly.for FA is the derivative of a generalized Fermi function. Numerical derivatives.
The codes are set up to test an approximation to the efficiency of a gamma ray detector - ..\..\robfit\TemplFit\eff\Welcome.doc .htm. The data is 63 simulated experimental points that are fitted to a six constant form involving a leading Pade approximant and a second Pade approximant in the exponential.
The original Nlfit, NlfitMP – calling an I-10 routine, NlfitMP calling a Watcom routine, and NlfitMP calling a Pascal routine were tested. All routines took the same number of steps ~ 60 to reach the final results. The final chi-square was found by comparing the 63 calculated values with the original values.
When these routines were run from a USB drive, there were no pauses from 1., and frequent pauses on the other 3 probably associated with overhead in opening the system files. These pauses were not present when the codes were run on the C drive. I-10 allows more than 16 digits (18 are used) in the decimal representation of a binary number. Watcom rounds to 16 digits, while Pascal rounds to 15 digits which accounts for most of the discrepancies above. I am not sure how the I-10 PolySA got below the Nlfit value.