[ 
https://issues.apache.org/jira/browse/MATH-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles resolved MATH-823.
-------------------------

       Resolution: Fixed
    Fix Version/s: 3.1

A "RandomGenerator" instance can now be passed at construction (revision 
1363604).
Please note that the "RandomDataImpl" instance has been deprecated.
                
> Distribution classes should allow randomData to be configured via constructor 
> or setter
> ---------------------------------------------------------------------------------------
>
>                 Key: MATH-823
>                 URL: https://issues.apache.org/jira/browse/MATH-823
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 3.0
>            Reporter: Steve Phelps
>            Assignee: Gilles
>            Priority: Minor
>             Fix For: 3.1
>
>
> In my application I would like to represent several different probability 
> distributions using polymorphism - see example below.  At compile-time the 
> distributions are declared of type RealDistribution.  These distributions are 
> then configured with concrete classes at run-time using, e.g. dependency 
> injection.  However, because there is no way to configure the underlying PRNG 
> -- ie the randomData field of these distributions, there is a danger of 
> introducing correlations into the random number streams through poor seed 
> management.  If I have dozens of distributions, each configured automatically 
> with a new RandomDataImpl() then there is the possibility that some of these 
> streams will share the same seed value introducing spurious correlations.  
> One solution to this would be to explicitly manage seed values for every 
> distribution in my simulation by calling reseedRandomGenerator().  However, 
> this introduces unnecessary complexity and dependencies throughout my code.  
> A far simpler solution for my use case would be to configure all the 
> distributions in my simulation to use the same singleton instance of 
> RandomDataImpl for their randomData field (eg using dependency injection), 
> thus ensuring truly independent distributions -  however currently the API 
> does not support this.
>  
> Could the Distribution classes be refactored to allow the randomData field to 
> be configured, eg through setters or via the constructor?   This would be 
> similar to the design of the distribution classes provided by the CERN colt 
> library, which I believe offers more flexibility in this respect.  It would 
> also be ideal, IMHO, if the Distribution objects were POJOs with zero-arg 
> constructors, which would then allow them to be configured using a 
> dependency-injection framework.
> public class Simulation {
>       RealDistribution interArrivalTimeDistribution;
>       
>       RealDistribution sizeDistribution;
>       
>       double t;
>       
>       public void run() {
>               t = 0;
>               while (true) {
>                       t += interArrivalTimeDistribution.sample();
>                       double magnitude = sizeDistribution.sample();
>                       System.out.println(t  + "\t" + magnitude);
>               }
>       }
>       public RealDistribution getInterArrivalTimeDistribution() {
>               return interArrivalTimeDistribution;
>       }
>       public void setInterArrivalTimeDistribution(RealDistribution 
> interArrivalTimes) {
>               this.interArrivalTimeDistribution = interArrivalTimes;
>       }
>       public RealDistribution getSizeDistribution() {
>               return sizeDistribution;
>       }
>       public void setSizeDistribution(RealDistribution xsizeDistribution) {
>               this.sizeDistribution = sizeDistribution;
>       }
>       
>       
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to