Hi,
2010/9/29 Gilles Sadowski <gil...@harfang.homelinux.org>:
>> Just to be sure: You propose to remove
>> public void setDistribution(TDistribution value)
>> Is this correct?
>
> Yes.
>
>> If so, another proposal - I'm not sure it's a clever one - is
>>
>> ---CUT---
>> public TDistribution setDistribution(TDistribution value) {
>> double n = value.getDegreesOfFreedom();
>> if (n > 2) {
>> n -= 2;
>> }
>>
>> final TDistribution newDistribution = new TDistributionImpl(n - 2);
>> distribution = newDistribution;
>> return newDistribution;
>> }
>> ---CUT---
>>
>> So that the new instance gets returned. As mentioned, I'm not sure
>> it's a good idea, but it would maintain the possibility to change
>> distribution. I think I'd prefer deleting the setDistribution-method
>> instead of this psudo-solution.
>
> There would remain the problem that, if "value" was instantiated with the
> other constructor:
> ---CUT---
> public TDistributionImpl(double degreesOfFreedom, double inverseCumAccuracy)
> {
> // ...
> }
> ---CUT---
> one could potentially have inconsistent behaviour since the
> "inverseCumAccuracy" parameter cannot be recovered (it is only accessible
> through a "protected" accessor method).
You're right. Didn't think of that.
>
>> TTestImpl: Would it be an idea to change the constructor to pass a
>> double degreeOfFreedom instead of a TDistribution?
>
> Yes, that would solve the problem.
What do you think of doing that? It would of course not be as nice
OO-wise, but still, the classes (as in t-test and the t-distribution)
are quite fixed (t-test would probably continue to use the
t-distribution etc.).
>
>
> Best,
> Gilles
>
Cheers,
Mikkel.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
