Re: [math] unit tests for FastMath

2010-08-28 Thread Phil Steitz
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

Re: [math] unit tests for FastMath

2010-08-28 Thread Ted Dunning
Some of these tests might benefit from choosing values from a highly skewed distribution. Gamma(0.01, 0.01), for instance will exercise small and large values much better than an exponential distribution. On Sat, Aug 28, 2010 at 4:49 PM, Luc Maisonobe wrote: > We could start by a random set of v

Re: [math] unit tests for FastMath

2010-08-28 Thread Luc Maisonobe
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

Re: [math] unit tests for FastMath

2010-08-28 Thread Bill Rossi
On Sat, 28 Aug 2010 18:25:23 -0400, wrote: > 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

Re: [math] unit tests for FastMath

2010-08-28 Thread Phil Steitz
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. >

[math] unit tests for FastMath

2010-08-27 Thread Luc Maisonobe
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 t