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 ted.dunning@gmail.com
 designates 209.85.216.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=ZSxC9D0SKBpttDendviRh7jKvUbiNvdFIlWYYdFebMPaJW11G3g7LpD3mcGm2qTim8
         Xn2AQSsEnogh9SLk+jgSEATaDEJCNhGMnByO6vleL83PDbmewH6lDqPnqxctl4RisZuV
         +eOl/aR6+Q5rg5P+dg2ZvBAOLJ/VFhlq+n344=
MIME-Version: 1.0
In-Reply-To: <4AE635AF.2050408@gmail.com>
References: <3796c6d50910261509n70c5f326yd5ab9eef2b74c92c@mail.gmail.com>
	<4AE635AF.2050408@gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Mon, 26 Oct 2009 17:21:00 -0700
Message-ID: <c7d45fc70910261721uf621f75ic81ad22bb29856f5@mail.gmail.com>
Subject: Re: [math] Generate random data using the Inverse CDF Method?
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001636b149994cbee20476dfa8bd

--001636b149994cbee20476dfa8bd
Content-Type: text/plain; charset=UTF-8

It is similar to what RandomDataImpl does, but the current type hierarchy is
a problem because it over-uses that interface/factory/implementation
pattern.  The result is confusing as can be, especially since virtually all
of the distributions have just one implementation and the factories aren't
polymorphic.  This causes the reader (*this* reader anyway) to be completely
convinced that there is more code hidden somewhere.

The approach suggested by Mikkel seems much better than the current one.

On Mon, Oct 26, 2009 at 4:50 PM, Phil Steitz <phil.steitz@gmail.com> wrote:

> > With this small change, a new class called
> > RandomDistributionWithInverseCumulativeProbability (again, who has a
> > better name?) could simply use the uniform generator and a class
> > implementing DistributionWithInverseCumulativeProbability to generate
> > random data from that distribution.
>
> This is essentially what RandomDataImpl does for the distributions
> that it supports. Support for more distributions would be a welcome
> addition.  I guess along the lines of what you are talking about
> above, it might make sense to add a single generic
> nextInversionDeviate method paramaterized by ContinuousDistribution.
> The implementation of this would use a uniform generator and
> inversion to generate deviates.  That would be simpler than creating
> separate classes for each distribution or adding random data
> generation to the distributions themselves.  It would also be more
> consistent with the current organization of the code, which locates
> random data generation in the random package.
>


-- 
Ted Dunning, CTO
DeepDyve

--001636b149994cbee20476dfa8bd--