[RsR] covrob --- some OOP-comments

[Peter Ruckdeschel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On Thu, 23 Mar 2006, Valentin Todorov wrote:

[snip]

> - using of access or methods. For example an access or getDistance() can
> either return the distances if present or recompute them each time. Ideal
> would be a kind of lazy evaluation when the distances are computed by first
> access and stored and the next time they are just returned, but I do not
> know how to do this in R.

This /is/ possible:
*define a class vectororNULL (as in the "Green Book")
*declare slot 'md' (or perhaps better 'distance') to be of class
vectororNULL
  in the setClass-command for 'covstruct'
*write an accessor function 'distance' (i.e. a method under a corresp.
S4-generic)
  which in the first place checks if the 'distance' is NULL and if so writes
  the values into the parent frame--- something like
  eval.parent(substitute( object using distance <- distanceValues ))

You might even think of allowing for more general distances than
Mahalanobis later ... which would imply that the name of such a
distance function should be linked to the 'distance' slot above
to form a more general class.

By means of S4, this may easily be done at a later stage of development,
because we simply could derive another class from 'covstruct'
with a corresponding additional slot of class 'newdistancestruct'
and declare covrob a generic function ...

> - S4 style show/plot/summary methods
>
> And in addition:
>
> - I would prefer to use inheritance instead of wrapping, i.e. define a base
> class for classic estimates, derive an abstract robust-estimates class from
> it and derive concrete robust estimates as necessary: mcd, M, ogk, etc.
This
> allowes to treat the objects polymorphically. I have tried to represent
> these ideas in the following class diagram:
>
> http://www.het2.org/wiki/upload/d/d6/Rrcov.gif

again my 2 cents:

[1] Just a question of understanding:

Are the methods displayed in Valentin's diagram (like show(),...)
meant to follow the S4 paradigm, i.e. dispatched according to a
generic, or are they meant to be functional slots (like in classical
OOP, e.g. C++)?
I think, given that there will only be a few different methods for some
few general classes, these methods should be S4 style methods.
The approach of functional slots has its advantages if we would have
new corresponding methods for (almost) every new instance of
the corresponding class but I think this does not apply here.

[2] more general:

In the "pure" OOP setup as in the Valentin's display,
I would suggest to go one step further and to treat the
control structures like alpha, maxiter,...  as follows:

* define an abstract method-class "CovMethodClass" with
slots "method" [a string as the current argument of covrob)] and
a slot "control.structure" of  class "Any".

* for each proposed derive a new descendant class to
"CovMethodClass";
  for these descendants, provide
- - suitable prototypes (for default instantiation)
- - accessor/replacement functions for the corresp. control structures.
- - an S4 method "getCovMethod" which produces a call to the
   corresponding method with all corresponding control-structures.

So calling covrob we either
# use the default instantiation (prototype)
   of the  (descendant) "CovMethodClass" - argument,
or
# beforehand instantiate a corresp. object and
   modify its control structures by the accessor/replacement functions.

In any case, we do not need to pass on any control structures
to 'covrob' directly, but rather an argument 'method'
of class "CovMethodClass" [or descendants] ;
in 'covrob' then simply use
    eval(getCovMethod(method))
which gives us a maximum of flexibility.

The same of course could be done in case of other control structures
like for the psi functions.

On the other hand, we should keep in mind that all these dispatching
operations will cost some computation time --- so we should
thoroughly test whether this gain in generality is worth this extra
effort.

[OT] : Valentin, what do you use as tool to draw your diagram?
We have been using some different tool for our S4 packages, but ours
did not yield half as good results as yours ; ( to be discussed offline ;-)

[snip]

> And last but not least - no comments but COMPLIMENTS for the covariance
> structure plots!

I join Valentin in this point!

Peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEItv01sqtPxlkLZ0RAnwiAJ9UnUPWkfTNBWmfsJa+ytJj7hL1GQCgqiU7
jBEN9MiPaCIwMwTs01h5nIM=
=41FO
-----END PGP SIGNATURE-----


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Peter.Ruckdeschel.vcf
Type: text/x-vcard
Size: 520 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-robust/attachments/20060323/00618f3f/attachment.vcf>