commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [math] Merge of interface and implementation of *Test classes in stat.inference
Date Sun, 05 Feb 2012 19:14:14 GMT
On Sun, Feb 05, 2012 at 07:29:05PM +0100, Thomas Neidhart wrote:
> On 02/03/2012 10:33 PM, Gilles Sadowski wrote:
> > On Fri, Feb 03, 2012 at 08:33:44PM +0100, Thomas Neidhart wrote:
> >> Hi,
> >>
> >> I have been working on the exceptions in the stat.inference package and
> >> have seen that all classes in this package follow the same scheme:
> >>
> >>  - Interface for a statistical test
> >>  - Implementation of this single interface
> >>
> >> e.g.
> >>
> >> ChiSquareTest
> >> ChiSquareTestImpl
> >>
> >> There was some effort in other packages, e.g. distribution to merge such
> >> constructs, and was wondering if not the same should apply here.
> >>
> >> I do not see an immediate benefit of having separate interface and
> >> implementation for a single Test, especially as there is no base Test
> >> interface.
> 
> Actually I would even go further, and change all the provided methods to
> static functions as this is the way they are actually used via the
> utility class TestUtils (see also the tutorial about Statistics).
> 
> TestUtils provides utility methods for each test. Therefore it
> instantiates each Test once and calls the corresponding methods. As all
> these tests are stateless, i.e. they do not store any data, there is no
> real need to do it that way.

Maybe I'm mistaken but it seems that you think that the "...Test" classes in
package "stat.inference" are somehow utilities for the CM unit tests (as is
actually the case for the "TestUtils" class) or some base class for CM unit
tests (?). That's not the case.
The name "ChiSquareTest" is the name of a "statistic test" (not a unit test
for a "ChiSquare" functionality):
  http://en.wikipedia.org/wiki/Chi-squared_test

The class may be used in the CM's unit testing framework but that does not
imply that it should be tailored to do just that; it is useful on its own,
as any other functionality available in CM.

[Sorry if I misunderstood what you were saying; in which case I did not get
it...]


Regards,
Gilles

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


Mime
View raw message