Thank you.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!
We have looked up these references with interest;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
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. Inwe are open in this issue; if the audience prefers longer names, that is oK for us....
particular would recommend 'pdf', 'cdf', 'quantile', and 'random' instead of
simply 'p', 'd', 'q', 'r' so that the expressions are very clear.
we chose the short ones in order to allude to the common naming in R.
This issue has already been dealt with in another thread of postings....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?
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
______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
