🚀 go-pugleaf

In article <81@radix> jimv@radix.UUCP (Jim Valerio) writes:
>The LINPACK benchmark reports on the error of the arithmetic operations.
>Here are the results when run on the 80960KB
>				norm. resid	resid		machep
>Double precision (extended)	1.50		6.66e-14	2.22e-16
>Double precision (double)	1.67		7.46e-14	2.22e-16

	I assume that "extended precision" refers to the 80-bit format
	commonly used in the 80x87 family - is this correct?

>Some months ago, John McCalpin (mccalpin@loligo.fsu.edu) reported in
><350@loligo.fsu.edu> some results from the 1000x1000 LINPACK benchmark
>that might confirm the same observation using results from the Sun 3/280.
>I say might because I am just presuming the results were run with an 68881,
>and may or may not have been compiled using an extended-precision evaluation
>model.  Jim Valerio jimv%radix@omepd.intel.com

	The original test was run with the Weitek FPA, since that is
	what people are going to use for number-crunching.  I did
	verify that the Sun passed the Paranoia test suite with all
	three floating-point options (Wietek, 68881, and software).

	I actually forgot about the extended-precision stack of the 68881
	when I ran the tests. I am re-running the 32-bit case now to see
	how much the extended precision changes the RMS error of the
	solution.
-- 
----------------------   John D. McCalpin   ------------------------
Dept of Oceanography & Supercomputer Computations Research Institute
mccalpin@masig1.ocean.fsu.edu		mccalpin@nu.cs.fsu.edu
--------------------------------------------------------------------