> >> 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? Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org