[
https://issues.apache.org/jira/browse/MATH-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162448#comment-14162448
]
Ole Ersoy commented on MATH-1124:
---------------------------------
Ah - OK. Another thought would be to have a wrapper for each distribution.
The wrapper would know how to generate samples and would also enable a fluid
API (Listenting for sample events, filtering, etc.) similar to what Reactive
Extensions have:
https://github.com/Reactive-Extensions/RxJS
Each Sampler could create it's own RNG or receive one:
//Constructor
Sampler.create();
Sampler.create(RNGInstance);
//A Single Sample
NormalDistributionSampler.create().sample();
//Fluid API
NormalDistributionSampler.create().take(3).takeLast(1);
//Listeners
NormalDistributionSampler.create().subscribe(listener);
Just throwing out some ideas at this point. First had this idea while while
watching this video:
http://www.infoq.com/presentations/game-functional-reactive-programming
In this case the actual sample() method on the distribution interface could be
kept simple (Actually this may be true in all cases):
sample(double[] uniformRNArray)
If the distribution needs more than one RN then the rest are on the array as
well. I think light weight parameters are better for testing.
> Instances of AbstractRealDistribution require a random generator.
> -----------------------------------------------------------------
>
> Key: MATH-1124
> URL: https://issues.apache.org/jira/browse/MATH-1124
> Project: Commons Math
> Issue Type: Bug
> Reporter: Ajo Fod
>
> A couple of observations:
> ... The default random generator takes a while to instantiate.
> ... Many functions of these distributions don't require a random generator.
> Generally speaking only sampling requires it.
> So, why force the default constructor to initialize with a new random
> generator ... why not use a global generic or simple generator?
> Or do away with random generator except for sampling?
> This issue was observed with the TDistribution class , but it is probably
> applicable to many classes as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)