You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Neidhart <th...@gmail.com> on 2012/02/03 20:33:44 UTC
[math] Merge of interface and implementation of *Test classes in
stat.inference
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.
What do you think?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes in stat.inference
Posted by Thomas Neidhart <th...@gmail.com>.
On Fri, Feb 10, 2012 at 11:36 AM, Luc Maisonobe <Lu...@free.fr>wrote:
> The unwritten consensus here for the last few months seems to be: there
> are different points of view which cannot be reconciled. So we gave up
> on achieving consistency and everyone does as he sees fit.
>
> Thomas and Sébastien, please don't put this on the plate once again. It
> is one the the deep wounds in our community and I would very much let it
> to rest and heal.
>
> Do as you want for the declarations. Don't try to achieve perfect
> consistency on this topic throughout the component.
>
>
Hi Luc,
thanks for the clarification. My intention was not to re-open this issue
and I am fine with the way you described it.
Thomas
Re: [math] Merge of interface and implementation of *Test classes
in stat.inference
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 10/02/2012 11:23, Gilles Sadowski a écrit :
> On Fri, Feb 10, 2012 at 10:58:30AM +0100, Sébastien Brisard wrote:
>> Hi Thomas,
>> 2012/2/10 Thomas Neidhart <th...@gmail.com>:
>>> On 02/10/2012 09:58 AM, Sébastien Brisard wrote:
>>>> Hello,
>>>>>
>>>>> I strongly prefer _not_ to have the (unchecked) exceptions in the signature.
>>>>> [Arguments mentioned numerous times in previous discussions...]
>>>>>
>>>> It's true it has been argued only recently. I was just wondering
>>>> whether it might be worth configuring checkstyle so as to make it
>>>> complain about unchecked exceptions in the signature. I'm not a CS
>>>> guru, so I don't know whether this is possible, but that would help
>>>> new committers!
>>>
>>> Yes indeed. I have search the ML about this topic, and had found this
>>> thread:
>>>
>>> http://markmail.org/message/ulhxnhplkja4iwbs?q=exceptions+list:org.apache.commons.dev/#query:exceptions%20list%3Aorg.apache.commons.dev%2F+page:1+mid:7iymuihzhy3nimum+state:results
>>>
>>> and the developer's guideline for CM also states this:
>>>
>>> All public methods advertise all exceptions that they can generate.
>>> Exceptions must be documented in both javadoc and method signatures and
>>> the documentation in the javadoc must include full description of the
>>> conditions under which exceptions are thrown.
>>>
>>> Could you give me some pointers about more recent discussions? I am
>>> basically fine with the approach chosen, but would like to be consistent
>>> in the way I contribute or edit code.
>>>
>> Here is a recent thread on this issue (as you can see, this thread was
>> caused by a faulty commit from me...).
>> Best regards,
>> Sébastien
>>
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201201.mbox/%3C20120113105913.GM6537%40dusk.harfang.homelinux.org%3E
>>
>
> It was not a faulty commit since you followed the rule stated in the
> developer's manual, as Thomas just pointed out. ;-}
> Let's note that the manual is not always up-to-date; but in this particular
> case, the difficulty is compounded because we don't all have the same
> feeling about this rule.
> I'd just say that we should not add systematically the exceptions to the
> signature. Those who like it would do it in the code they often contribute
> to, hopefully not cluttering the code which they don't have to test very
> often...
The unwritten consensus here for the last few months seems to be: there
are different points of view which cannot be reconciled. So we gave up
on achieving consistency and everyone does as he sees fit.
Thomas and Sébastien, please don't put this on the plate once again. It
is one the the deep wounds in our community and I would very much let it
to rest and heal.
Do as you want for the declarations. Don't try to achieve perfect
consistency on this topic throughout the component.
thanks,
Luc
>
>
> Best regards,
> Gilles
>
>
> [1] And by the fact that the exception debate has generated so much
> discussion in the past 18 months that I didn't want to write a document
> about the new exceptions, that would be irrelevant a few weeks later...
>
> ---------------------------------------------------------------------
> 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
Re: [math] Merge of interface and implementation of *Test classes in
stat.inference
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Fri, Feb 10, 2012 at 10:58:30AM +0100, Sébastien Brisard wrote:
> Hi Thomas,
> 2012/2/10 Thomas Neidhart <th...@gmail.com>:
> > On 02/10/2012 09:58 AM, Sébastien Brisard wrote:
> >> Hello,
> >>>
> >>> I strongly prefer _not_ to have the (unchecked) exceptions in the signature.
> >>> [Arguments mentioned numerous times in previous discussions...]
> >>>
> >> It's true it has been argued only recently. I was just wondering
> >> whether it might be worth configuring checkstyle so as to make it
> >> complain about unchecked exceptions in the signature. I'm not a CS
> >> guru, so I don't know whether this is possible, but that would help
> >> new committers!
> >
> > Yes indeed. I have search the ML about this topic, and had found this
> > thread:
> >
> > http://markmail.org/message/ulhxnhplkja4iwbs?q=exceptions+list:org.apache.commons.dev/#query:exceptions%20list%3Aorg.apache.commons.dev%2F+page:1+mid:7iymuihzhy3nimum+state:results
> >
> > and the developer's guideline for CM also states this:
> >
> > All public methods advertise all exceptions that they can generate.
> > Exceptions must be documented in both javadoc and method signatures and
> > the documentation in the javadoc must include full description of the
> > conditions under which exceptions are thrown.
> >
> > Could you give me some pointers about more recent discussions? I am
> > basically fine with the approach chosen, but would like to be consistent
> > in the way I contribute or edit code.
> >
> Here is a recent thread on this issue (as you can see, this thread was
> caused by a faulty commit from me...).
> Best regards,
> Sébastien
>
> http://mail-archives.apache.org/mod_mbox/commons-dev/201201.mbox/%3C20120113105913.GM6537%40dusk.harfang.homelinux.org%3E
>
It was not a faulty commit since you followed the rule stated in the
developer's manual, as Thomas just pointed out. ;-}
Let's note that the manual is not always up-to-date; but in this particular
case, the difficulty is compounded because we don't all have the same
feeling about this rule.
I'd just say that we should not add systematically the exceptions to the
signature. Those who like it would do it in the code they often contribute
to, hopefully not cluttering the code which they don't have to test very
often...
Best regards,
Gilles
[1] And by the fact that the exception debate has generated so much
discussion in the past 18 months that I didn't want to write a document
about the new exceptions, that would be irrelevant a few weeks later...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes in
stat.inference
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Fri, Feb 10, 2012 at 11:08:12AM +0100, Thomas Neidhart wrote:
> On 02/10/2012 10:58 AM, Sébastien Brisard wrote:
> > Here is a recent thread on this issue (as you can see, this thread was
> > caused by a faulty commit from me...).
> > Best regards,
> > Sébastien
> >
> > http://mail-archives.apache.org/mod_mbox/commons-dev/201201.mbox/%3C20120113105913.GM6537%40dusk.harfang.homelinux.org%3E
>
> Thanks,
>
> the point is, if you want to be able to document all exceptions in the
> javadoc that _can_ be thrown by a method, it is a very tedious process
> if you only advertise them in javadoc.
>
> The solution from Luc to temporarily change the base exceptions to
> checked ones helps with this (and I usually do it that way), as you see
> immediately which exceptions you have missed.
>
> Otherwise you have to dig into the code and follow all invoked method
> calls, which can be quite some work and is also error-prone as they
> might change as well, leading to an unmaintainable bunch of exceptions
> in javadoc.
You have to do that only if the doc is wrong or incomplete or there is no
unit test for testing all the preconditions.
Avoiding these is the rule we all agree to try and follow.
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes
in stat.inference
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/10/2012 10:58 AM, Sébastien Brisard wrote:
> Here is a recent thread on this issue (as you can see, this thread was
> caused by a faulty commit from me...).
> Best regards,
> Sébastien
>
> http://mail-archives.apache.org/mod_mbox/commons-dev/201201.mbox/%3C20120113105913.GM6537%40dusk.harfang.homelinux.org%3E
Thanks,
the point is, if you want to be able to document all exceptions in the
javadoc that _can_ be thrown by a method, it is a very tedious process
if you only advertise them in javadoc.
The solution from Luc to temporarily change the base exceptions to
checked ones helps with this (and I usually do it that way), as you see
immediately which exceptions you have missed.
Otherwise you have to dig into the code and follow all invoked method
calls, which can be quite some work and is also error-prone as they
might change as well, leading to an unmaintainable bunch of exceptions
in javadoc.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes in stat.inference
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Thomas,
2012/2/10 Thomas Neidhart <th...@gmail.com>:
> On 02/10/2012 09:58 AM, Sébastien Brisard wrote:
>> Hello,
>>>
>>> I strongly prefer _not_ to have the (unchecked) exceptions in the signature.
>>> [Arguments mentioned numerous times in previous discussions...]
>>>
>> It's true it has been argued only recently. I was just wondering
>> whether it might be worth configuring checkstyle so as to make it
>> complain about unchecked exceptions in the signature. I'm not a CS
>> guru, so I don't know whether this is possible, but that would help
>> new committers!
>
> Yes indeed. I have search the ML about this topic, and had found this
> thread:
>
> http://markmail.org/message/ulhxnhplkja4iwbs?q=exceptions+list:org.apache.commons.dev/#query:exceptions%20list%3Aorg.apache.commons.dev%2F+page:1+mid:7iymuihzhy3nimum+state:results
>
> and the developer's guideline for CM also states this:
>
> All public methods advertise all exceptions that they can generate.
> Exceptions must be documented in both javadoc and method signatures and
> the documentation in the javadoc must include full description of the
> conditions under which exceptions are thrown.
>
> Could you give me some pointers about more recent discussions? I am
> basically fine with the approach chosen, but would like to be consistent
> in the way I contribute or edit code.
>
Here is a recent thread on this issue (as you can see, this thread was
caused by a faulty commit from me...).
Best regards,
Sébastien
http://mail-archives.apache.org/mod_mbox/commons-dev/201201.mbox/%3C20120113105913.GM6537%40dusk.harfang.homelinux.org%3E
> Thanks,
>
> Thomas
>
> ---------------------------------------------------------------------
> 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
Re: [math] Merge of interface and implementation of *Test classes
in stat.inference
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/10/2012 09:58 AM, Sébastien Brisard wrote:
> Hello,
>>
>> I strongly prefer _not_ to have the (unchecked) exceptions in the signature.
>> [Arguments mentioned numerous times in previous discussions...]
>>
> It's true it has been argued only recently. I was just wondering
> whether it might be worth configuring checkstyle so as to make it
> complain about unchecked exceptions in the signature. I'm not a CS
> guru, so I don't know whether this is possible, but that would help
> new committers!
Yes indeed. I have search the ML about this topic, and had found this
thread:
http://markmail.org/message/ulhxnhplkja4iwbs?q=exceptions+list:org.apache.commons.dev/#query:exceptions%20list%3Aorg.apache.commons.dev%2F+page:1+mid:7iymuihzhy3nimum+state:results
and the developer's guideline for CM also states this:
All public methods advertise all exceptions that they can generate.
Exceptions must be documented in both javadoc and method signatures and
the documentation in the javadoc must include full description of the
conditions under which exceptions are thrown.
Could you give me some pointers about more recent discussions? I am
basically fine with the approach chosen, but would like to be consistent
in the way I contribute or edit code.
Thanks,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes in stat.inference
Posted by Sébastien Brisard <se...@m4x.org>.
Hello,
>
> I strongly prefer _not_ to have the (unchecked) exceptions in the signature.
> [Arguments mentioned numerous times in previous discussions...]
>
It's true it has been argued only recently. I was just wondering
whether it might be worth configuring checkstyle so as to make it
complain about unchecked exceptions in the signature. I'm not a CS
guru, so I don't know whether this is possible, but that would help
new committers!
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes in
stat.inference
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> [...]
> What do you think?
No idea.
> @Exceptions: while working on the migration to the new exceptions in
> this package, I tried to stick to the rules from Phil/Luc:
>
> - add @throws clause to javadoc
> - add throws declaration to method signature
>
> for each individual exception that can be thrown.
>
> This can lead to pretty elaborate signatures, see f.e.
> WilcoxonSignedRankTest#wilcoxonSignedRankTest(double[], double[], boolean)
>
> Is it ok like that?
I strongly prefer _not_ to have the (unchecked) exceptions in the signature.
[Arguments mentioned numerous times in previous discussions...]
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes
in stat.inference
Posted by Thomas Neidhart <th...@gmail.com>.
> 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
Hi,
I have started to work on this issue (see MATH-739).
For the ChiSquareTest I have a question though:
The test was split up into two interfaces:
- ChiSquareTest
- UnknownDistributionChiSquareTest
with one class implementing both (ChiSquareTestImpl).
When merging interface and implementation this subtle difference would
get lost. When looking at the T-Test, it contains also methods for
different tests:
- one-/two-sample
- one-/two-sided
- paired/unpaired
- homoscedastic/heteroscedastic
so imo it should be fine to do the same for the Chi-square test.
What do you think?
@Exceptions: while working on the migration to the new exceptions in
this package, I tried to stick to the rules from Phil/Luc:
- add @throws clause to javadoc
- add throws declaration to method signature
for each individual exception that can be thrown.
This can lead to pretty elaborate signatures, see f.e.
WilcoxonSignedRankTest#wilcoxonSignedRankTest(double[], double[], boolean)
Is it ok like that?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes in stat.inference
Posted by sebb <se...@gmail.com>.
On 5 February 2012 18:29, Thomas Neidhart <th...@gmail.com> 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.
AFAIK, the only disadvantage of static methods is that they cannot be
overridden by a subclass.
But if this is not required, then static methods are slightly easier to use.
> Thomas
>
> ---------------------------------------------------------------------
> 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
Re: [math] Merge of interface and implementation of *Test classes
in stat.inference
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/05/2012 08:14 PM, Gilles Sadowski wrote:
> 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.
No, I am not referring to a unit test. There is really a TestUtils class
in the stat.inference package (see also the tutorial) that provides
access to the different statistical test implementations (like ChiSquare).
> [Sorry if I misunderstood what you were saying; in which case I did not get
> it...]
I wanted to say that in most cases people will use a statistical test in
such a way:
TestUtils.chiSquareTest(expected, observed);
which is btw how it is described in the tutorial.
If this is the case, and as the tests itself are state-less, all of them
can be implemented as pure functions -> static methods
There is no need to instantiate an instance of, e.g. ChiSquareTest to
call the appropriate method.
Hope this makes my argument clearer.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes in
stat.inference
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sun, Feb 05, 2012 at 09:17:27PM +0100, Thomas Neidhart wrote:
> On 02/05/2012 08:14 PM, Gilles Sadowski wrote:
>
> [snip]
>
> > [Sorry if I misunderstood what you were saying; in which case I did not get
> > it...]
>
> I think the confusion came from the fact that there are actually 2
> TestUtils classes in CM ;-)
Yes, sorry.
Then, more knowledgeable people will hopefully join in to discuss the
suggested changes.
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes
in stat.inference
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/05/2012 08:14 PM, Gilles Sadowski wrote:
[snip]
> [Sorry if I misunderstood what you were saying; in which case I did not get
> it...]
I think the confusion came from the fact that there are actually 2
TestUtils classes in CM ;-)
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes in
stat.inference
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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
Re: [math] Merge of interface and implementation of *Test classes
in stat.inference
Posted by Thomas Neidhart <th...@gmail.com>.
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.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Merge of interface and implementation of *Test classes in
stat.inference
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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.
>
> What do you think?
+1 for merging interface and single implementation.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org