commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] unit tests for FastMath
Date Sun, 29 Aug 2010 01:58:18 GMT
Luc Maisonobe wrote:
> Le 29/08/2010 00:25, Phil Steitz a écrit :
>> Luc Maisonobe wrote:
>>> Hi all,
>>> I have started integrating the FastMath class from MATH-375. I have not
>>> committed anything for now as I am first fixing numerous checkstyle
>>> errors (more than 300) and wanted to have one clean commit to simplify
>>> patching both trunk for 3.0 and branch 2.X.
>>> One less obvious problem is unit tests. The current tests (which I
>>> converted to Junit 4) depend on a few external classes that themselve
>>> depend on a LGPL library, and this library doesn seem to be available in
>>> maven repositories. This imply that we cannot include the library in the
>>> release, and we cannot either use it as an optional dependency for tests.
> Bill is willing to offer the dependency library under the same terms as
> FastMath as he explained in the Jira comments for MATH-375. That could
> be another way to solve the problem (and would be another fine addition
> to [math]).

Excellent.  Agreed this looks like another good addition.  Thanks, Bill!

>>> I would suggest to completely remove this library and create tests
>>> simply by storing reference values in files that we would read. It would
>>> be similar to the existing tests for random values or stats. The file
>>> could of course be created using dfp or any other reference high
>>> precision package (having several different reference sources would be
>>> better IMHO). We would remove the random aspect of the tests, which may
>>> or may not be a problem.
>> Sounds like a reasonable approach.  Can you explain a little more
>> what the tests do and what you have in mind in terms of data
>> coverage?  In particular, what are the "random aspects" of the
>> tests?  I know the answer here is really RTFP (p = patch ;)
>> but hey, I am a little lazy this evening.
> We could start by a random set of values just like the current tests do.
> The current test structure is basically one big accuracy test for each
> function, consisting in 10000 calls to random values obtained thanks to
> Math.random and normalized to the appropriate domain of the function
> (-inf; +inf) or (-1; +1) or (0; +inf) ...
> Then the FastMath implementation is compared with a reference computed
> with extended precision by the dfp library, and some features of the
> library are also used to compute precisely the error in terms of ulps.
> We could also add specific non random values for some corner cases (NaN,
> infinities, zero, one, big integers closes to multiples of pi for the
> argument reduction of angles ...).
> Of course, we would also add values corresponding to issues raised by
> users after they are solved.
> Luc
>> Phil
>>> Luc
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message