     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.


