Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1423173912.128441268007987211.JavaMail.jira@brutus.apache.org>
Date: Mon, 8 Mar 2010 00:26:27 +0000 (UTC)
From: "Phil Steitz (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (MATH-310) Supply nextSample for all
 distributions with inverse cdf using inverse transform sampling approach
In-Reply-To: <61566037.1256650139475.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MATH-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842511#action_12842511 ] 

Phil Steitz commented on MATH-310:
----------------------------------

The problem is that to be really useful, this requires that you expose the RandomData instance and allow the RandomGenerator to be configured.   This contributes to the aroma of bad separation of concerns, IMO.    To make it a little clearer why I see this as bad separation of concerns, consider that you could accomplish the same thing by putting the impl in each of the distributions and then having RandomDataImpl use the impls in the distributions.  That seems backwards to me. 

> Supply nextSample for all distributions with inverse cdf using inverse transform sampling approach
> --------------------------------------------------------------------------------------------------
>
>                 Key: MATH-310
>                 URL: https://issues.apache.org/jira/browse/MATH-310
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 2.0
>            Reporter: Mikkel Meyer Andersen
>            Priority: Minor
>         Attachments: patch_proposal
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> To be able to generate samples from the supported probability distributions, a generic function nextSample is implemented in AbstractContinuousDistribution and AbstractIntegerDistribution. This also gives the possibility to override the method if better algorithms are available for specific distributions as shown in the small example with the exponential distribution.
> Because the nextExponential is used several places: in nextPoisson it can be replaces by an instance if the ExponentialDistribution and in ValueServer it can as well, although maybe not in as natural maner as the other. 
> This problem with the Exponential is a special problem. In general the nextSample-approaches immediately gives the possibility the sample from all the distributions with inverse cdf instead just only a couple.
> Only AbstractContinuousDistribution and AbstractIntegerDistribution extends AbstractDistribution, and both AbstractIntegerDistribution and AbstractContinuousDistribution has an inverseCumulativeProbability-function. But in AbstractContinuousDistribution the inverse cdf returns a double, and at AbstractIntegerDistribution it - naturally - returns an integer. Therefor the nextSample is not put on AbstractDistribution, but on each extension with different return types.
> RandomGenerator as parameter instead of getting a RNG inside the nextSample, because one typically wants to use the same RNG because often several random samples are wanted. Another option is to have a RNG as a field in the class, but that would be more ugly and also result in several RNGs at runtime.
> The nextPoisson etc. ought to be moved as well, if the enhancement is accepted, but it should be a quick fix.
> Tests has to be written for this change as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.