On Mon, Jul 16, 2012 at 04:39:41PM -0700, Phil Steitz wrote:
> On 7/16/12 2:46 PM, Gilles Sadowski wrote:
> > Hi.
> >
> > Referring to the discussion here:
> >   https://issues.apache.org/jira/browse/MATH-764
> >   https://issues.apache.org/jira/browse/MATH-823
> >
> > Do we agree:
> >  * To add new constructors to the distribution classes (in package
> >    "o.a.c.m.distribution") that take a "RandomGenerator" (in package
> >    "o.a.c.m.random") as an argument?
> +1
> >  * That this argument (reference) will be stored in the distribution
> >    object but can be manipulated from outside (e.g. "setSeed") so that
> >    the class is not strictly immutable? [Immutability is impossible to
> >    enforce since there is no way to copy such an object.]
> +1
> >  * That the distribution classes do not need a setter for the RNG, nor a
> >    a method to re-seed the RNG? [I.e. if a user wants a new RNG, he must
> >    instantiate a new distribution object.]
> +1 for no setter, -1 for no reseed.

Why do you need a "reSeed" method since it can be called on the RNG object
that was passed to the constructor of the distribution?
I.e. it is the user's responsibility to keep a reference to the RNG object
if he wants to later modify it.
IMO, it makes it more obvious that the RNG is "owned" by the user's code,
not by the distribution instance.

> >  * That the ad-hoc code of the sampling methods currently in
> >    "RandomDataImpl" (in package "o.a.c.m.random") will be moved over to the
> >    "sample" method in the correpsonding distribution class?
> +1
> >  * That "RandomData" and "RandomDataImpl" will be refactored so that methods
> >    that duplicate functionality transferred to the distribution will
> >    deprecated in 3.1 and removed in 4.0?
> -0  If we keep these classes, which I am inclined to support
> (combined into one), they should delegate implementations to
> distributions (exactly the reverse of how it is now).

No problem. But IIUC, this will require instantiating a distribution object
for each call; in some situations, this will be an obvious performance loss
(e.g. when sampling from a distribution with same parameters).

> >  * That the interface "RandomData" and its unique implementation
> >   ("RandomDataImpl") will be merged in 4.0?
> +1
> 

Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to