Date: Mon, 10 Mar 2008 09:24:14 -0400 From: David Schultz <das@FreeBSD.ORG> To: Mike Silbersack <silby@silby.com> Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Bruce Evans <brde@optusnet.com.au> Subject: Re: cvs commit: src/sys/i386/include _types.h Message-ID: <20080310132414.GA2698@zim.MIT.EDU> In-Reply-To: <20080310015118.L43534@odysseus.silby.com> References: <200803051121.m25BLE03035426@repoman.freebsd.org> <20080305230954.X55190@odysseus.silby.com> <20080307122252.Y11033@delplex.bde.org> <20080310015118.L43534@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080310132414.GA2698>