On 7/16/12 5:17 PM, Gilles Sadowski wrote:
> 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.
I get your point, but in my view, any random data generation API
should expose a reseed method to reseed the underlying source of
randomness. So rather than force users to hold a reference to the
RandomData instance provided at construction time to do this
indirectly, I think it would be more convenient / more complete to
provide the method in the same API that does the data generation,
which is now going to be the distribution.
>
>>> * 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).
Yeah, we will probably want to cache these.
Phil
>
>>> * That the interface "RandomData" and its unique implementation
>>> ("RandomDataImpl") will be merged in 4.0?
>> +1
>>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
