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 MATH375. 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 MATH375. 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!
Phil
>>> 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, email: devunsubscribe@commons.apache.org
>>> For additional commands, email: devhelp@commons.apache.org
>>>
>>
>> 
>> To unsubscribe, email: devunsubscribe@commons.apache.org
>> For additional commands, email: devhelp@commons.apache.org
>>
>
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
