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 2014/01/12 15:03:29 UTC
[math] Suggestion to refactor BinomialConfidenceInterval
Hi,
we had some preliminary discussion about changing the
BinominalConfidenceInterval class in MATH-1086.
Right now the class provides some non-static methods to create various
ConfidenceIntervals, and I was proposing to change them to be static.
Another option would be to allow sub-classing by defining an interface
(or abstract base class) to create such an interval:
public interface BinomialConfidenceInterval {
ConfidenceInterval createInterval(int numberOfTrials,
int numberOfSuccesses,
double confidenceLevel);
}
With subclasses for the individual methods, e.g. Wilson or
NormalApproximation.
Phil suggested that we should still create static methods to create them
easily, e.g. in TestUtils.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Suggestion to refactor BinomialConfidenceInterval
Posted by Thomas Neidhart <th...@gmail.com>.
On 01/14/2014 09:16 PM, Phil Steitz wrote:
> On 1/13/14, 1:20 PM, Thomas Neidhart wrote:
>> On 01/12/2014 06:46 PM, Phil Steitz wrote:
>>> On 1/12/14, 6:03 AM, Thomas Neidhart wrote:
>>>> Hi,
>>>>
>>>> we had some preliminary discussion about changing the
>>>> BinominalConfidenceInterval class in MATH-1086.
>>>>
>>>> Right now the class provides some non-static methods to create various
>>>> ConfidenceIntervals, and I was proposing to change them to be static.
>>>>
>>>> Another option would be to allow sub-classing by defining an interface
>>>> (or abstract base class) to create such an interval:
>>>>
>>>> public interface BinomialConfidenceInterval {
>>>> ConfidenceInterval createInterval(int numberOfTrials,
>>>> int numberOfSuccesses,
>>>> double confidenceLevel);
>>>> }
>>>>
>>>> With subclasses for the individual methods, e.g. Wilson or
>>>> NormalApproximation.
>>> I am +1 for this. Calling conversion of current methods to static
>>> 0) and above 1), seems to me there are two other reasonable options:
>>> 2) do nothing - leaving the methods non-static preserves extensibility
>>> 3) use an abstract class instead of interface - I think we may be
>>> getting carried away with preference for this approach and I think
>>> it would be silly in this case
>>>
>>> So my preference order is 1), 0), 2), 3). I guess TestUtils is OK
>>> as the home for the static convenience methods in cases 1), 2), 3).
>> Option 3 would make sense to avoid duplicating the checkParameters
>> method which is currently used by all the different getXXXInterval methods.
>
> Good point. Maybe best to just do go the abstract class route then.
>>
>> But we can also make it package private and static in TestUtils.
>
> Seem unnatural placement, so I guess I am +1 for 3)
ok good, I will then make the change.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Suggestion to refactor BinomialConfidenceInterval
Posted by Phil Steitz <ph...@gmail.com>.
On 1/13/14, 1:20 PM, Thomas Neidhart wrote:
> On 01/12/2014 06:46 PM, Phil Steitz wrote:
>> On 1/12/14, 6:03 AM, Thomas Neidhart wrote:
>>> Hi,
>>>
>>> we had some preliminary discussion about changing the
>>> BinominalConfidenceInterval class in MATH-1086.
>>>
>>> Right now the class provides some non-static methods to create various
>>> ConfidenceIntervals, and I was proposing to change them to be static.
>>>
>>> Another option would be to allow sub-classing by defining an interface
>>> (or abstract base class) to create such an interval:
>>>
>>> public interface BinomialConfidenceInterval {
>>> ConfidenceInterval createInterval(int numberOfTrials,
>>> int numberOfSuccesses,
>>> double confidenceLevel);
>>> }
>>>
>>> With subclasses for the individual methods, e.g. Wilson or
>>> NormalApproximation.
>> I am +1 for this. Calling conversion of current methods to static
>> 0) and above 1), seems to me there are two other reasonable options:
>> 2) do nothing - leaving the methods non-static preserves extensibility
>> 3) use an abstract class instead of interface - I think we may be
>> getting carried away with preference for this approach and I think
>> it would be silly in this case
>>
>> So my preference order is 1), 0), 2), 3). I guess TestUtils is OK
>> as the home for the static convenience methods in cases 1), 2), 3).
> Option 3 would make sense to avoid duplicating the checkParameters
> method which is currently used by all the different getXXXInterval methods.
Good point. Maybe best to just do go the abstract class route then.
>
> But we can also make it package private and static in TestUtils.
Seem unnatural placement, so I guess I am +1 for 3)
Phil
>
> 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] Suggestion to refactor BinomialConfidenceInterval
Posted by Thomas Neidhart <th...@gmail.com>.
On 01/12/2014 06:46 PM, Phil Steitz wrote:
> On 1/12/14, 6:03 AM, Thomas Neidhart wrote:
>> Hi,
>>
>> we had some preliminary discussion about changing the
>> BinominalConfidenceInterval class in MATH-1086.
>>
>> Right now the class provides some non-static methods to create various
>> ConfidenceIntervals, and I was proposing to change them to be static.
>>
>> Another option would be to allow sub-classing by defining an interface
>> (or abstract base class) to create such an interval:
>>
>> public interface BinomialConfidenceInterval {
>> ConfidenceInterval createInterval(int numberOfTrials,
>> int numberOfSuccesses,
>> double confidenceLevel);
>> }
>>
>> With subclasses for the individual methods, e.g. Wilson or
>> NormalApproximation.
>
> I am +1 for this. Calling conversion of current methods to static
> 0) and above 1), seems to me there are two other reasonable options:
> 2) do nothing - leaving the methods non-static preserves extensibility
> 3) use an abstract class instead of interface - I think we may be
> getting carried away with preference for this approach and I think
> it would be silly in this case
>
> So my preference order is 1), 0), 2), 3). I guess TestUtils is OK
> as the home for the static convenience methods in cases 1), 2), 3).
Option 3 would make sense to avoid duplicating the checkParameters
method which is currently used by all the different getXXXInterval methods.
But we can also make it package private and static in TestUtils.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Suggestion to refactor BinomialConfidenceInterval
Posted by Phil Steitz <ph...@gmail.com>.
On 1/12/14, 6:03 AM, Thomas Neidhart wrote:
> Hi,
>
> we had some preliminary discussion about changing the
> BinominalConfidenceInterval class in MATH-1086.
>
> Right now the class provides some non-static methods to create various
> ConfidenceIntervals, and I was proposing to change them to be static.
>
> Another option would be to allow sub-classing by defining an interface
> (or abstract base class) to create such an interval:
>
> public interface BinomialConfidenceInterval {
> ConfidenceInterval createInterval(int numberOfTrials,
> int numberOfSuccesses,
> double confidenceLevel);
> }
>
> With subclasses for the individual methods, e.g. Wilson or
> NormalApproximation.
I am +1 for this. Calling conversion of current methods to static
0) and above 1), seems to me there are two other reasonable options:
2) do nothing - leaving the methods non-static preserves extensibility
3) use an abstract class instead of interface - I think we may be
getting carried away with preference for this approach and I think
it would be silly in this case
So my preference order is 1), 0), 2), 3). I guess TestUtils is OK
as the home for the static convenience methods in cases 1), 2), 3).
Phil
>
> Phil suggested that we should still create static methods to create them
> easily, e.g. in TestUtils.
>
> 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