Ted Dunning wrote: > It is similar to what RandomDataImpl does, but the current type hierarchy is > a problem because it over-uses that interface/factory/implementation > pattern.
Explain what you mean. There is one interface and one implementation for RandomData. The result is confusing as can be, especially since virtually all > of the distributions have just one implementation and the factories aren't > polymorphic. What factories? These were removed in 2.0. This causes the reader (*this* reader anyway) to be completely > convinced that there is more code hidden somewhere. Where? Is it the abstract classes that are confusing you? These make implementing actual distributions much easier. Phil > > The approach suggested by Mikkel seems much better than the current one. > > On Mon, Oct 26, 2009 at 4:50 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > >>> With this small change, a new class called >>> RandomDistributionWithInverseCumulativeProbability (again, who has a >>> better name?) could simply use the uniform generator and a class >>> implementing DistributionWithInverseCumulativeProbability to generate >>> random data from that distribution. >> This is essentially what RandomDataImpl does for the distributions >> that it supports. Support for more distributions would be a welcome >> addition. I guess along the lines of what you are talking about >> above, it might make sense to add a single generic >> nextInversionDeviate method paramaterized by ContinuousDistribution. >> The implementation of this would use a uniform generator and >> inversion to generate deviates. That would be simpler than creating >> separate classes for each distribution or adding random data >> generation to the distributions themselves. It would also be more >> consistent with the current organization of the code, which locates >> random data generation in the random package. >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
