cvs commit: src/sys/i386/include _types.h

[David Schultz]

On Mon, Mar 10, 2008, Mike Silbersack wrote:
> 
> On Fri, 7 Mar 2008, Bruce Evans wrote:
> 
> >On Wed, 5 Mar 2008, Mike Silbersack wrote:
> >>As I've said in the past, I'd really, really, really like to see 
> >>regression tests for any change to the floating point functions.  The 
> >>types of changes you've been making are not easy to verify just by 
> >>looking at diffs.
> >
> >I run local regression tests of 4 billon to 64 billion cases per
> >function or 1.3 trillion cases for 125 functions a 36-hour run on a
> >2.2HGz UP system.  These are not well organized enough for commit.
> >You will have to trust that they are done before commit (or after on
> >some other machines) :-).  I mostly use semi-exhaustive (exhaustive
> >for 1-arg float precision functions) checks on machine-generated args.
> >This seems to find problems more routinely than smarter tests, up to
> >at least double precision.  das@ committed some smarter tests.
> 
> So clean them up and commit them.  I'm not saying that anyone will 
> actually run them, but at least they will be there if one chooses to.
> 
> >OTOH, I barely tested the changes to float_t and double_t.  These types
> >are so rarely used that they are never used in /usr/src, at least in
> >my old src tree, except for my uncommitted changes in libm parts.
> >
> >Bruce
> 
> The subsequent thread has taught me that I don't care enough about 
> floating point to participate in this thread beyond the regression test 
> point. :)

I don't necessarily agree with this change, but in Bruce's
defense, it's a one-line change, and there aren't many useful ways
you could test it. The only thing it would break is buggy
third-party apps.  As for the argument that ``The types of changes
[Bruce has] making are not easy to verify just by looking at
diffs,'' well, yes---if you don't care about floating point by
your own admission, that's certainly the case. ;-)

I have checked in a bunch of tests for various libm functions.
This works great for things like ilogb that are always supposed to
return the exact answer, okay for things like fe* that are often
limited by architectural differences, and not so great for
functions like exp() and sin() that are not always exact. The best
way to test the functions in the last category is to look for the
worst error via random or systematic search, and make sure that
error is below some threshold. But this requires tests that run
for a long time, and the tests themselves won't work without a
reference implementation that's more accurate than (or at least
different from) libm's implementation. I have many tests that use
mpfr or SunOS 5.10 the math library as a reference, but none of
that can be committed. Hence, for these functions, I generally
only commit tests for corner cases.

On top of all that, tests often fail on Alpha, IA64, powerpc, and
sparc64, since these architectures rely partly on software
emulation of some features, which is incomplete in FreeBSD, and I
don't have time to fix it.