[Rd] request for comments --- package "distr" --- S4 Classes
for Distributions
Peter Ruckdeschel
Peter.Ruckdeschel at uni-bayreuth.de
Tue Feb 3 15:21:19 MET 2004
Hi Gregory,
>>after some discussions with Martin Maechler and Josef Leydold
>>(WU Wien),
>>we have felt the need for some package that should allow for an
>>object-orientated
>>approach to distributions.
>>
>>
>
>Great!
>
>
Thank you.
>>Our small group at Bayreuth now has developed a package "distr" which
>>tries to fill this gap, implementing distributions by means of
>>S4--classes.
>>
>>
>You may find some value in looking at the Java distribution library that I
>created a couple of years ago by porting the R distribution functions:
>
>http://statdistlib.sourceforge.net/
>
>
>A separate java implementation of the basic distribution classes is included
>as part of the Hydra package for MCMC,
>
>http://hydra-mcmc.sf.net
>
>
>
We have looked up these references with interest;
on the one hand, JAVA seems even more appropriate to our approach
with its concept of private/public interfaces, and on first glance, the
way we
attach functions as slots to objects seems to be more-JAVA/C++ -like
than conformal to the S4 concept,
but we wanted to stay *within* R to facilitate the use for the common
R-user
and to have available the full power of S in syntax and R as to computing.
We have inveseted some time into the decision how to implement the
methods that
we call "constitutive", i.e. r,d,p,q --- as slots as we did it or as
methods in the common
S4-concept. The main reason for our decision was:
Our classes are sort of "closed" under *(almost) arbitrary*
transformations ---
the result of a transformation being again *one* new distribtion that
only has be created
*once* for each transformation.
In particular, once the slots r,d,p,q is filled by an assignement of the
kind Z= X+Y [or any other transformation of distributions implemented],
in our solution, you can call d(Z)(x) which is the accessor function for
slot d
of Z returning a function which is then evaluated at x [or r,p,q]
arbitrarily often for different arguments x without redefining d.
Within the S4-concept, however, as far as we understand it, you would
probably
have to create a new class for each sort of transformation, e.g.
"ConvolutedDistribution", and corresponding methods r,d,p,q for this class
which would then be called by the method dispatcher.
But
+ either an object Z of class "ConvolutedDistribution" would not know
how to produce
r,d,p,q a priori, and for any call d(Z,x) convolution would have to be
redone, which would not
be effective,
+ or any object Z which results from the assignement Z=X+Y would have to
produce a new class [and corresponding derived methods....]!
This is what we meant when calling r,d,p,q "constitutive" for a
distribution in
our manual.
>I would recommend giving more descriptive names to the methods. In
>particular would recommend 'pdf', 'cdf', 'quantile', and 'random' instead of
>simply 'p', 'd', 'q', 'r' so that the expressions are very clear.
>
>
we are open in this issue; if the audience prefers longer names, that is
oK for us....
we chose the short ones in order to allude to the common naming in R.
>>as subclasses of either of the two the subclasses
>>"AbscontDistribution" or
>>" DiscreteDistribution".
>>
>>
>
>It is not at all clear to me what an 'AbscontDistribution' is. Perhaps you
>are referring to a continuous distribution?
>
>
This issue has already been dealt with in another thread of postings....
>You may also want to consider how to deal with multivariate distributions.
>
>
We might, but actually we doubt to be the right ones to do so...
[At least we would like to call in some *real* experts in this domain.]
Anyway, our class concept is open and we have already thought of such an
extension
>>This approach seems very appealing to us from a conceptual viewpoint:
>>
>Yes this is very interesting, particularly if you extend it to handle
>multivariate distributions.
>
>
Would you like to give us advice in this direction?
You are definitely welcome to :-)
Thank you for your interest,
Peter, Matthias, Thomas, Florian
More information about the R-devel
mailing list