Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.212.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=RR/O6Rk0CkmGj8dXktZVE2AbUue9aHM/fHenqzZIBAd4+Ni5/e3o6gU5aAmDN9BURU
         TwwfmlRGzO8eBcxDA+3FlAJB+OBed/IQcrpcJyQwcYgCxdsRuBeqYYC8h0DxS4mw5VBY
         gTtbB0WfQevaCMYJJb3pTBv6NZgQUZrfotwHM=
Message-ID: <4C798CD3.7040407@gmail.com>
Date: Sat, 28 Aug 2010 18:25:23 -0400
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] unit tests for FastMath
References: <4C78546C.9020805@free.fr>
In-Reply-To: <4C78546C.9020805@free.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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

Phil
> 
> Luc
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org