commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [MATH] Test failure in Continuum
Date Mon, 06 Aug 2012 21:42:38 GMT
On 8/6/12 2:28 PM, Gilles Sadowski wrote:
> On Mon, Aug 06, 2012 at 12:44:24PM -0700, Phil Steitz wrote:
>> On 8/6/12 11:41 AM, Gilles Sadowski wrote:
>>>>> [...]
>>>>>>> The RandomData class (or whatever it would be called) does indeed
seem useful. If we plan to keep it, we should probably make sure that there is a sample/next/...
method in that class for EVERY distribution, as some of them are missing, if I remember correctly.
Perhaps this is a separate issue though?
>>>>>> All have the method now, but the impls delegate to RandomDataImpl.
>>>>> They do not.
>>>> The method is in the interface.  There is a default, inversion-based implementation
in the abstract base class.  Not all distributions override the default impl.
>>>> The ones that do delegate to the specialized methods in RandomDataImpl
>>>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> No; as indicated before (cf. message referred to below), the distribution
>>> classes do not delegate anymore to "RandomDataImpl", since revision 1363604
>>> (resolution of MATH-764 and MATH-823).
>> Sorry, my mistake.  I see the code has been duplicated.  I will see
>> if I can modify the methods in RandomDataImpl to use the impls in
>> the distribution classes.  Should be possible by creating instances
>> using the configured RandomGenerator.
> Yes, that was what I also proposed when we started talking about
> transferring the (sampling) code from RAndomDataImpl over to the "sample()"
> methods.
>>  See more below.
>>>>>> In some cases, there is nothing better implemented than just inversion,
provided by the default inversion sampler.  That is OK.  What we need to do is just move the
implementations of the default and specialized samplers to the actual distribution classes.
 These can't be static, as they use the RamdomData instance.  I will take care of this.
>>>>> Thanks for reading fully this message
>>>> I don't get the desire to make sample() static.
>>> There is no such desire stated in that message.
>>> The proposed static method is a "helper" that will take everything needed as
>>> arguments. It will be defined in the appropriate distribution class, to be
>>> called both by "sample()" from that class and by the convenience methods in
>>> "RandomDataImpl".
>> OK, I now think I get what you mean.  Non-static methods of
>> "RandomDataImpl" could use static methods from the distribution
>> classes, passing the configured RandomGenerator as an argument.   Is
>> that what you mean?
> Yes! :-)
>>  I don't know how much direct usage the static
>> methods in the distribution classes would get; since most actual
>> examples involve generating sequences using the same generator
>> repeatedly (so sample() is more natural).
> I totally agree. They would exist only for the sake of not duplicating the
> sampling code.
>>  I guess "RandomDataImpl"
>> would then not have to instantiate distributions, but there is not
>> much overhead to creating the ones we have, so not sure it is worth
>> the effort to add all of these methods.
> Fine then. I'd also prefer not to create new public methods just for the
> sake of a convenience class.
> I.e. we could mention (in "RandomDataImpl") that the convenience comes at a
> slight efficiency cost. [And that for heavy usage of sampling, one should
> use the distribution classes directly.]

OK, sorry to be a little thick on this.  I think I can do this.


> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message