commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] unit tests for FastMath
Date Sat, 28 Aug 2010 22:49:51 GMT
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]).

>> 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.


> 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:

View raw message