On Thu, 8 Dec 2005, Mike Silbersack wrote:
On Thu, 8 Dec 2005, Bruce Evans wrote:
Whoever makes the changes would write the regression tests :-). Mine
are't sufficently general to commit. In batch mode which takes about
10 hours on a 2GHz Athlon to check all cases for floats, they are
currently reporting the following errors on amd64:
The regression tests don't need to be exhaustive, you could just pick a few
values throughout the range of each function you test, and make a regression
test like:
x = 3/2;
if (x != 1.5)
printf("FP regression!\n");
Heck, you could throw all the calculations into one file.
That wouldn't be very good.
My local tests are:
- ucbtest. Normally I run it using -DNTESTS=1000000 -DNREGIONS=64. This
tests a million cases of some functions (not the more exotic ones like
gamma or the more standard ones like sqrt()). I used to think that it
found most problems; now I'm not so sure. It somehow only reports
errors of 2.9 ulps for hardware i387 cos() where my own tests easily
find errors of several gulps (giga-ulps) in hardware cos() as a side
effect of testing just 65536 cases for fdlibm cosf(). The difference
may be that ucbtest mainly tests small args by my test tests mainly
large args where hardware i387 trig is known to be very bad. But ucbtest
somehow doesn't report problems for cos() near pi/2 for its test of
cos(), although it must know that there are problems since it correctly
determines the (in)accuracy of the i387's internal pi using another
test. (The internal pi has only 66 digits, so cos(M_PI_2) can have
only ~66-53 = 13 binary digits of precision, with 40 binary digits wrong,
and in fact the magic 66 can easily be guessed by looking at the wrong
digits in cos(M_PI_2) -- the lower 40 digits are all 0.)
- exhaustive testing of float functions relative to double functions. Now
has a batch mode and many parameters to change. One parameter is the
"stride" -- float args in bits are stepped through using step "stride",
so stride = 1 gives exhaustive testing and stride = 0x10000 gives very
fast non-exhaustive testing.
- non-exhaustive testing with stride = any for double complex and float
complex functions relative to alternative implementations of the same
function. stride = 1 would give exhaustive testing but would take too
long to run (~100000 years for float complex and 2**62 times longer
than that for double complex). Must be edited to change parameters.
- hacked versions of previous to reduce to non-complex functions.
- some performance tests. The best one uses uniform distribution with
a parametrized number of regions. It also has some hacks for random
distribution (this shows that branch misprediction slows down things
as expected. Hopefully most data isn't random, so branch misprediction
is rare).
- missing: uniform and random distributions generally. Special values.
All needed for non-float cases.
ucbtest and my tests show:
- how hard it is to find all broken cases without using exhaustive testing.
It's larger than any regression tests that I want to write.
- that regressions found by existing regression tests don't get fixed for
12+ years.
- that it's useful to write independent tests. They find independent bugs.
Bruce
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
