As already stated, I agree with Ted. I think we should have a nextSample() on the distributions. I'm also concerned that this creates a need for another part of the library (RNG), but it _is_ already in the library, just like using erf- og gamma-functions. What about making the RNGImp a thread-safe singleton and using this in the nextSample-implementations?
And the nextSample() can be implemented in an abstract class providing inverse cdf, and distributions with better sample generators just override this? 2009/10/27 Ted Dunning <ted.dunn...@gmail.com>: > Are you against adding any nextSample() method to distributions at all > (regardless of the quality of the implementation)? > > Or just unhappy about adding nextSample() hooked to a bad implementation? > > The first opinion, I just don't understand. The second can be dealt with by > putting in good implementations or by throwing UOE. > > I have a little bit of sympathy as a developer for separating all sampling > from the distributions, but I have no sympathy at all with this as a user. > I think of a distribution as something that you can take the density of, > (often) get the cumulative distribution from and get a sample from. I know > in my heart of hearts that there is something down deep that is probably > called a <mumble>DistributionGenerator. I even know that underneath that, > there is likely to be a uniform distribution generator. What what I think > about when using a system is "sampling from a distribution" just like > anybody trained in statistics would. That means that I expect > <mumble>Distribution.nextSample() to exist. I know that it might be fast or > slow, but having hunted up the distribution I want, I *don't* want to have > to imagine what class might generate the distribution I want. > > The key here is what a user of the system thinks. Not how an implementor > thinks. > > On Mon, Oct 26, 2009 at 6:01 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > >> What I >> am -1 on is adding (potentially poor) random data generation to the >> distributions implementations. >> > > > > -- > Ted Dunning, CTO > DeepDyve > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
