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! 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, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
