Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.210.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=ACUF2dpyPvlSEK5NvwJ5hg1eJnHit/xUEshWIFNTLQ/xvOKdvYmEED4mffLkwSDYaF
         dP9//hEmdBwPSbb2qBjtjxtLdyBhswYpKWyXJkf4Fio4JqLJd15rRcMONWWzjo0ZW4Sr
         CIO2zWJGMJ6WA1V5TNfjopiinPv3KVXPIq248=
Message-ID: <4AE6465E.5040809@gmail.com>
Date: Mon, 26 Oct 2009 21:01:18 -0400
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] Generate random data using the Inverse CDF Method?
References: <3796c6d50910261509n70c5f326yd5ab9eef2b74c92c@mail.gmail.com>
	 <4AE635AF.2050408@gmail.com>
	 <c7d45fc70910261653nbc6d389s6dffb3d4d930210d@mail.gmail.com>
	 <4AE639E4.2080702@gmail.com>
	 <3796c6d50910261711y279cfe05x992c716db723c91b@mail.gmail.com>
	 <c7d45fc70910261724q4a822616o5789e355578dc6fa@mail.gmail.com>
 <3796c6d50910261733v520c6f9bxef9e4e14ffc8f86@mail.gmail.com>
In-Reply-To: <3796c6d50910261733v520c6f9bxef9e4e14ffc8f86@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Mikkel Meyer Andersen wrote:
> Ted: No, I mean with the discrete inverse cdf. But anyway. Thanks for
> clarifying the points.
> 
> Phil, if you're not convinced, I'll be happy to provide a
> patch-draft/prototype of code so you can see exactly what I mean?
> 
> If we were to put a generator in the distributions (for supporting the
> specialised generators), should this method then just be parameterised
> by a RandomGenerator? Or what would be a proper approach?

That is part of the reason that I would rather see random data
generation remain in the random package.  That way the
RandomGenerator can be easily configured.  It is also better
separation of concerns.  There are lots of things that one can do
with probability distributions, including generate random data
following them.  That does not mean all of these things should be in
the distribution implementation classes.

I now understand your point about a missing interface. I would be
fine with adding a HasInverse or HasInverseCumulativeDistribution
interface to mark invertible distributions and then adding a generic
nextDeviate to RandomDataImpl.  I am also open to deprecating
RandomData/RandomDataImpl and refactoring the setup there.  What I
am -1 on is adding (potentially poor) random data generation to the
distributions implementations.

Phil
> 
> 2009/10/27 Ted Dunning <ted.dunning@gmail.com>:
>> That was Phil. (not that it matters)
>>
>> +1 for the idea of a default generator for all distributions that define a
>> cumulative density.
>>
>> +1 as well for specialized implementations where possible that over-ride the
>> default generator even if it exists.
>>
>> I can't imagine much dispute on either of these points because they satisfy
>> the general principle of doing the best we can for all cases as well as for
>> special cases.
>>
>> I also completely agree with Mikkel with not understanding why the
>> generation of deviates is separated from the distribution.
>>
>> On Mon, Oct 26, 2009 at 5:11 PM, Mikkel Meyer Andersen <mikl@mikl.dk> wrote:
>>
>>> Ted, sorry hadn't seen your e-mail before sending mine.
>>>
>>> Yes, I agree in you point of having specialised good algorithms. But
>>> in lack of such methods, I'd prefer being able to have a general
>>> method, although it might be bad compared to a specialised one.
>>>
>>> 2009/10/27 Phil Steitz <phil.steitz@gmail.com>:
>>>> Thanks.  That's what I was missing. I would still rather see the
>>>> implementations in the random package and for common distributions,
>>>> e.g. Poisson, pick a method that is well-suited for the distribution.
> 
> ---------------------------------------------------------------------
> 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