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?
>
> +1
>
>> 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.).
>
> I was just wondering if anyone needed the flexibility to pass an instance of
> the distribution. In fact, does it even make sense to have several
> implementations of this interface?
In general, yes it does: if somebody wants to implement the cumProb
(or density, but that's not relevant for the t-test) in another way
than done by TDistributionImpl. By changing the constructor, we
disallow this and dictate the usage of the included TDistributionImpl
- but I suspect that it won't be a problem in practise. I can't come
up with a "real" reason why not to use (cumProb from)
TDistributionImpl, so I won't have a problem with dictating the usage
of TDistributionImpl when immutability is obtain in return.
Cheers,
Mikkel.
>
>
> Regards,
> Gilles
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
