[RsR] covrob --- some OOP-comments

[Valentin Todorov]

Dear all,

I was waiting with my comments on Peter&Heinrich's contribution until I have
a working example (in rrcov/robustbase) but following Peter I'll add now my
2 cent.

I agree completely with Peter's comments:
- encapsulation by a control object instead of ellipses
- 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.
- 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

and I have just uploaded a new version of rrcov to CRAN containing some of
the implementation (psi-functions for constrained M-estimates).

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

best regards,
Valentin

----- Original Message ----- 
From: "Peter Ruckdeschel" <Peter.Ruckdeschel using uni-bayreuth.de>
To: "Peter Filzmoser" <P.Filzmoser using tuwien.ac.at>;
<R-SIG-Robust using stat.math.ethz.ch>
Sent: Wednesday, March 22, 2006 6:06 PM
Subject: Re: [RsR] covrob --- some OOP-comments


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Peter and Heinrich,
>
>> During the last weeks we worked on a flexible wrapper
>> for combining functions for robust estimation of
>> location and covariance. This was seen as one of the
>> main tasks of the working group on multivariate analysis
>> in Treviso.
>
> First of all thank you for providing this very flexible interface.
> I had a look on your description in
> http://www.statistik.tuwien.ac.at/rsr/groups/mva/Abstract.pdf
> and like to comment on it:
>
> (*) argument function.control:
>
> For the moment, I agree with you  that the "..." as argument will
> probably do.
>         In the long run, however, a "capsulated" argument
> function.control would
> help to avoid name clashes in the named arguments (e.g. by partial
> matching!)
> and hence IMHO should be preferred.
> This applies in particular if external developpers will call your
> function within
> their functions and hence have to pass their additional arguments
> together with
> yours to their functions.
> Also a clearer structure is imposed and function calls become easier to
> read than in
> an unstructured list.
>
> (*) accessor/replacement functions:
>
> You do not mention accessor/replacement functions for your S4-class
> "covstruct".  Replacement might not be desired external to /covrob/.
> Like in the lm-structure, however, it would be nice if you could inspect
> the slots of an object of class "covstruct" by such accessor functions.
> E.g., if A is of class "covstruct", cov.classic(A) should return slot
> cov.classic of A. As to programming, this is only book-keeping, but it
> is handy for the user...
>
> (*) S3 paradigm for plot,summary,print
>
> Last issue: Why would you follow the S3-paradigm in defining plot,
> print, summary
> for "covstruct"? Wouldn't it be more consistent with S4 to also register
> these functions
> as S4 generics and then deriving particular methods by "setMethod"?
> This would save you from declaring them in style  <function>.<class>.
> More important, (later) S4 could give you more flexibility , e.g. using
> a different dispatch
> if plot takes a second (differently) classed argument.
>
> Having made these points, I want to emphasize that this is /not/ to
> criticize your work, which of course is a valuable step towards the goals
> set in Treviso.
>
> Thank you already
> Peter
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEIYQY1sqtPxlkLZ0RAve4AKC46HztUh+xsNDBrMpn01i3VwgT7ACgiIjB
> HlV7Ih5J7R1I/tw1/06jP8M=
> =kMVe
> -----END PGP SIGNATURE-----
>
>


--------------------------------------------------------------------------------


> _______________________________________________
> R-SIG-Robust using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-sig-robust
>