2002-05-28 10:51:51-0600  Nelson H. F. Beebe  <beebe@math.utah.edu>

	* In several t*.c files, harmless initializations (to ZERO) have
	  been added for a few variables to eliminate compiler warnings of
	  ``possible use before definition''.

------------------------------------------------------------------------
2002-05-28 10:07:31-0600  Nelson H. F. Beebe  <beebe@math.utah.edu>

	* Add volatile qualifiers to most floating-point variables in the
	  t*.c test functions.  This eliminates large bit loss errors
	  arising from code optimization on some systems, and in
	  principle, should produce results that are independent of the
	  optimization level used for the ELEFUNT test code.  This is as
	  it should be, because the ELEFUNT tests are evaluating the
	  precompiled run-time library, and thus, results should be the
	  same for all compilers that use that same run-time library.

	  The keyword volatile is defined to be empty in common/elefunt.h
	  in a preStandard-C environment.

	  Note that volatile declaration qualifiers are not a complete
	  replacement for STORE(), although they would be if they were
	  uniformly, and correctly, implemented (it has been found that
	  volatile is incorrectly handled in several Java implementations,
	  so deficiencies in C and C++ implementations would not be
	  surprising).  The use of STORE() ensures that correct processing
	  is carried out even on older systems which lack support
	  volatile.

------------------------------------------------------------------------
2002-05-28 06:05:01-0600  Nelson H. F. Beebe  <beebe@math.utah.edu>

	* Rearrange code for C version of ELEFUNT into a new, cleaner,
	  directory structure, to avoid code duplication:

		./common
		./dp
		./dp/logs
		./lib
		./qp
		./qp/logs
		./sp
		./sp/logs

------------------------------------------------------------------------
2002-05-27 10:26:18-0600  Nelson H. F. Beebe  <beebe@math.utah.edu>

	* The C version of ELEFUNT can now be compiled with either C or
	  C++ compilers, since the code has been restricted to a common
	  subset of those two languages.

------------------------------------------------------------------------
2002-05-27 10:22:57-0600  Nelson H. F. Beebe  <beebe@math.utah.edu>

	* There is now a C version of a quadruple-precision ELEFUNT test
	  package, following the development last week of a
	  quadruple-precision Fortran version.

------------------------------------------------------------------------
2002-05-27 10:21:53-0600  Nelson H. F. Beebe  <beebe@math.utah.edu>

	* The pseudo-random number generators sran(), ran(), and qran()
	  have been augmented with sranset(long n), ranset(long n), and
	  qranset(long n) to set the initial seed to n; a zero seed is
	  replaced by a default seed.  These functions return the old seed
	  as a long integer.  This change was made so that each test
	  program will use the same sequence of random numbers, which was
	  not previously the case when the tests were run standalone,
	  versus collected in tallsp, talldp, and tallqp.

	  Each elementary function test uses the same sequence of
	  pseudo-random numbers, where the sequence is determined by an
	  initial seed.

	  The default initial pseudo-random number generator seed can be
	  changed at compile time by defining a positive value for the
	  macro INITIALSEED, add, e.g.,

		XDEFINES=-DINITIALSEED=271828182

	  to the make command line.

	  The default initial seed can also be changed at run time by
	  assigning a positive (long) integer value to the environment
	  variable INITIALSEED, e.g.,

		env INITIALSEED=314159265 ./talog > talog.lst-xxx

	  A zero value of INITIALSEED chooses the internal default.

------------------------------------------------------------------------
2002-05-27 10:21:34-0600  Nelson H. F. Beebe  <beebe@math.utah.edu>

	* The default number of tests with random arguments is now under
	  compile-time control: add, e.g.,

		XDEFINES=-DMAXTEST=200000

	  to the make command line.

	  The compiled-in limit can later be overridden at run time by
	  assigning a positive integer value to the environment variable
	  MAXTEST, e.g.,

		env MAXTEST=25000 ./talog > talog.lst-xxx

	  With 200,000 tests, the quadruple-precision tallqp program takes
	  15 min to run on Sun Solaris 2.8 on a 400MHz UltraSPARC II
	  system (quadruple-precision arithmetic is done is software).

	  With 200,000 tests, the quadruple-precision tallqp program takes
	  15 sec on a 600MHz Intel Pentium III (80-bit arithmetic is done
	  in hardware).

	  The default of MAXTEST=2000 was made prior to 1980, when
	  machines were much slower.  It therefore seemed worthwhile to
	  investigate the sensitivity of the reported bit losses to the
	  value of MAXTEST, and to the value of INITIALSEED.

	  Unfortunately, the results are a quite sensitive to both of
	  those values.  On a 600MHz Intel Pentium III (with hardware
	  80-bit arithmetic), a tests with MAXTEST=2,000,000 and two
	  different initial seeds (0 and 271828182) took 145 sec to run,
	  and produced these bit loss differences:

		------------------------------------------------------------------------------------------
										Run 1	Run 2	Difference
		------------------------------------------------------------------------------------------
		ACOS(X) VS TAYLOR SERIES					19.50	18.91	-0.59
		ACOS(X) VS TAYLOR SERIES					 9.19*	 8.94*	-0.25*
		ACOS(X) VS TAYLOR SERIES					 7.89	 6.89	-1.00
		SINH(X) VS C*(SINH(X+1)+SINH(X-1))				 5.27	 5.28	 0.01
		TAN(X) VS 2*TAN(X/2)/(1-TAN(X/2)**2)				 2.20	 2.28	 0.08
		TAN(X) VS 2*TAN(X/2)/(1-TAN(X/2)**2)				 2.22	 2.25	 0.03
		COT(X) VS (COT(X/2)**2-1)/(2*COT(X/2))				 2.30	 2.39	 0.09
		TANH(X) VS (TANH(X-1/8)+TANH(1/8))/(1+TANH(X-1/8)TANH(1/8))	 2.39	 2.47	 0.08
		------------------------------------------------------------------------------------------
		* ==> RMS bit loss; otherwise, results are for maximum relative error bit loss

	  Although the differences between runs are usually below 0.1 bit,
	  there are three exceptions on this system, with the largest
	  difference of 1 bit.

	  I then made a similar experiment, with MAXTEST=20,000,000, which
	  made the run times about 25 minutes each, with these results:

		------------------------------------------------------------------------------------------
										Run 1	Run 2	Difference
		------------------------------------------------------------------------------------------
		ACOS(X) VS TAYLOR SERIES					22.95	24.80	 1.85
		ACOS(X) VS TAYLOR SERIES					10.97*	12.70*	 1.73*
		ACOS(X) VS TAYLOR SERIES					 9.99	 9.30	-0.69
		XSQ**1.5 VS XSQ*X						 2.24	 2.22	-0.02
		TAN(X) VS 2*TAN(X/2)/(1-TAN(X/2)**2)				 2.33	 2.64	 0.31
		TAN(X) VS 2*TAN(X/2)/(1-TAN(X/2)**2)				 2.27	 2.55	 0.28
		TAN(X) VS 2*TAN(X/2)/(1-TAN(X/2)**2)				 2.36	 2.66	 0.30
		TAN(X) VS 2*TAN(X/2)/(1-TAN(X/2)**2)				 2.31	 2.56	 0.25
		------------------------------------------------------------------------------------------
		* ==> RMS bit loss; otherwise, results are for maximum relative error bit loss

	  The differences are even larger, which is certainly not
	  satisfactory.  Evidently, further testing will turn up instances
	  of even larger maximum relative error, even if most of the RMS
	  bit losses have converged.
	------------------------------------------------------------------------
