On Mon, Oct 31, 2011 at 2:56 PM, cwinter <chwinterho...@aol.com> wrote:

>
> Phil Steitz wrote:
> >
> > Maybe it would be best to eliminate IntegerDistribution then and
> > merge Distribution and ContinuousDistribution, so we have two roots
> > - DiscreteDistribution and ContinuousDistribution.   The only reason
> > really to have DiscreteDistribution is if we want to support
> > distributions of RVs over sample spaces that are not subsets of Z.
> > There does not seem to be much enthusiasm for that (i.e.
> > parameterizing the type of the domain of the distribution and pmf),
> > so we might as well just collapse Discrete and Integer.   Once you
> > pull out Discrete/Integer, there is not much value any more in
> > Distribution as a parent, so why not just drop both
> > IntegerDistribution and Distribution and move to two roots with
> > doubles / ints as domains and contracts cleaned up to deal with
> > discrete vs continuous cases consistently.
> >
> > Phil
> >
>
> I'm absolutely convinced that the approach with two roots suits our needs.
> However, for real-valued random variables we need a hierarchy of
> distribution interfaces because not every distribution on the reals has a
> density.


Lordy...  this is really more complicated than necessary.

You could just have a single interface/abstract class and have
distributions throw UOE if they can't do something like give you a density.
 At most, a marker interface or hasDensity() indicator method is needed.

Commons projects and commons math really have a tendency to over-engineer
the type structure instead of just going and implementing some useful
functions.


> Thus I'd like to keep Distribution and ContinuousDistribution. But
> maybe we could change the names to put more emphasis on the domain of
> the distribution, e.g. to RealDistribution and ContinuousRealDistribution.
>

Do you have any code for which this distinction would actually matter more
than a hairs-breadth?


> ... Apart from this, a separate interface for more general discrete
> distributions is indeed not required.
>

I should bless you for saying this at least.

Reply via email to