A new version of genprec in which numbers are in base 2^32 is now complete. Numbers have the following representation in the new base: a[prec+1]=2 for positive numbers, 0 for negative numbers. a[prec],a[prec-1],....a[1] are the coefficients in a=a[prec]/2^32 + a[prec-1]/(2^32)^2 + a[prec-2]/(2^32)^3 + ... a[0] contains the exponent: a = a * (2^32)^a[0]. All a[i] are unsigned integers. The exponent a[0] is actually a[0] + 2^30 (called zshiftexponent in the code) so that a[0] <2^30 refer to negative powers of 2^32, a[0]=2^30 refers to (2^32)^0=1, and a[0]>2^30 refers to positive powers of 2^32. Hopefully, the user will not need to take much note of this: it should be transparent to the user. The new version has to contain some assembly language in order to gain access to the 64 bit register EAX,EDX which arithmetic in base 2^32 requires. (This assembly language need not be understood by the user: it should be transparent.) The assembly language code works for 486 and pentium processers but may not work for upcoming processers with 64 bits and/or risc (we do not know enough about assembly language to have an opinion). The new include files contain a letter d. They are: genprecd.h,genlind.h,polyd.h,cgnprecd.h,paded.h,seriesd.h,cgenlind.h, cpolyd.h,cpaded.h, and cseriesd.h (only the spelling of cgenprec.h had to be shortened because of the 8 letter DOS rule for file naming). The examples are the same as for genprec.h except that they have a d somewhere in their name: genpdex.cpp, genpdex2.cpp, gnlindex.cpp, polydex.cpp, cgenpdex.cpp, padedex.cpp, seresdex.cpp, seresdx2.cpp, cgnlndex.cpp, cpolydex.cpp, cpadedx.cpp, cpadedx1.cpp, cpadedx2.cpp, cpadedx3.cpp, cpadedx4.cpp. There is another fact which shouuld be noted. We were not able to write assembly code using dynamic dimensioning. There are six variables (x,y,z, zL,z11, and z22) used in the assembly language codes. These are dimensioned right after the extern statements in genprecd.h and marked "assembly language variables". They are set for up to 600 significant figures. The number of dimensions presently set is 200. For 10000 figures, one would have to reset this to 2000 by retyping the one line presently containing the 200's. As an eccentricity: we have gone back to spelling the real logarithm routine zlog rather than zln but still spell the complex logarithm routine cln. The user need not know or understand any of the following; however, if the user asks why was genprec revised-- The reason why genprec has been revised is that the speed is proportional to the square of the length of the base. Since 2^32 is more than twice as long as 2^15 in any base (2^32=4294967296 in base 10 whereas 2^15=32768 in base 10), the speed of the revised genprecd should be 4 times the speed of genprec (the more nearly so as the precision increases). The argument about the square of the length of the base follows: consider multiplying two 4 digit numbers and two 8 digit numbers according to the "school" scheme: .... ........ it may be seen that there are 4^2 x .... x ........ or 8^2 numbers between the long lines ______, _________ _______________ each of which requires a machine .... ........ language multiplication, .... ........ .... ........ The higher the base, the fewer the .... ........ number of machine language multiplica- _________ ........ tions required (the number is inversely ....... ........ proportional to the square of the base). ........ ........ The base may not exceed the length of ______________ the EAX register (FFFF FFFF + 1). Obviously, addition and subtraction require a number of machine language operations inversely proportional to the base. Harder thought show division and multiplication to be equivalent. Asymptotically, additions and subtrac- tions are dominated the multiplication and division. There is other "overhead" in a multiple precision code like genprec: tests whether numbers are positive or negative for example and other things. This overhead is also ultimately dominated by the requirements of multiplication and division. A bad division code might increase in time like (number of significant figures)^2 log(number of significant figures) which has to be guarded against. Of course, multiplication is not done exactly in the "school" manner in the pictures above. One has to a little cleverer, but to suggest that schemes suggested by "fast fourier transform techniques" somehow change the above conclusions seems to us farfetched. genprec and genprecd are programming languages. The Bailey programs presently available are in many ways similar to them and in other ways different. The Bailey programs could be a programming language related to fortran as genprec is related to C++. But there are Bailey programs available which translate an existing fortran program (or a section of an existing fortran program) to a multiple precision program. (We have watched how people expert in fortran and the use of Bailey's programs do this.) We have no such thing available. genprec will not transform a C++ code to a multiple precision code. A text editor which does this could be written (a C++ code is a text file). But we have not done it. genprec contains things which the Bailey programs do not (principally functions for solving linear systems, solving polynomials, forming Pade approximants to power series, and manipulating power series). Also, complex arithmetic is completed covered in genprec. The Baileys programs may contain things which genprec does not (probably some codes related to wavelet theory). We are not certain about these statements. One may very well wonder about the speed of programs created for genprec and the speed of programs created by translating fortran code to multiple precision using Bailey's programs. The result for a benchmark program which does about 85,000 each of divide, multiply, subtract, and add are significant figures genprec genprecd Bailey 300 333 seconds 135 seconds 235 seconds 600 436 788 The benchmark program is brief. It was written in fortran and translated to multiple precision by a person expert in fortran and use of the Bailey programs. The genprec and genprecd programs were written by us. The 85,000 divides could be replaced by multiplications in the benchmark. When this was done, in the case of 600 significant figures, genprecd required 228 rather than 436 seconds, and Bailey required 441 seconds rather than 788 seconds. These are similar results reflecting the difficulty of multiple precision division as opposed to multiplication.