commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [Math] Issues 764 and 823
Date Tue, 17 Jul 2012 04:08:51 GMT
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



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


Mime
View raw message