[RsR] covrob --- some OOP-comments

[Peter Ruckdeschel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi

On Thu, 23 Mar 2006, Valentin Todorov wrote:
>On Thu, 23 Mar 2006, Peter Ruckdeschel wrote:
>>On Thu, 23 Mar 2006, Valentin Todorov wrote:

>>>- using of accessor methods. ...

[snip]

>>*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 ))
>
>
>Yes, everything is in the last line, but I still do not know which object
>will be modified.

sorry for having been too imprecise here: 'object' was meant to be the
argument of
class 'covstruct' of the function 'distance' (resp. getDistance) upon
which 'distance'
dispatched by the S4 mechanism.
The evaluation in the parent frame should imitate the
call-by-reference-passing
of arguments as in your sketch of C++  code below:

>In C++ and friends I would define
> dist=null;
>in the constructor and then write a get-accessor like this
>
>vector getDistance(){
> if(dist==null)
> dist = computeDIstance();
> return dist;
>}

[snip]

>>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 had S4 classes in mind, but it is not that easy to express this in UML:
>particularly, the classes Cov, Mcd, Ogk and Mest are S4 classes returned by
>the functions cov, covMcd, covOgk and covMest respectively. Most of their
>methods - show/plot/summary - are implemented for Cov or the abstract CovR
>and can be applied polymorphic on the subclasses.

Thank you for this clarification.

>>[2] more general:
>>
>>In the "pure" OOP setup as in the Valentin's display,
>
>...
>
>this needs further thinking and discussing...

This was just a suggestion anyway!
  --- I was only wondering  how to cope with control structures
which may not so easily be organized in a hereditary class-hierarchy,
but (see below)

>>The same of course could be done in case of other control structures
>>like for the psi functions.
>
>
>have a look at my implementation of the psi-functions used for the
>constrained M-estimates in covMest() in the new version of rrcov that
> I uploaded yesterday
>(still stays in Incoming, I'll send it you offline).


Now it's in the regular archive :-) --- and I have had a look into it:

In fact your code to covMest () shows how to cope with
varying control stuctures in a simpler and computational
efficient manor than with my proposed S4 classes!
(except for the passing of single parameters of control,
 which then should be avoided)

>>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.
>
>
>very important. A straightforward, !OOP implementation can be more than
>twice faster than S4 implementation.

I had imagined something like that -- but of course without
computational evidence!

>I'll provide some more computational evidence.

Thank you -- touché;

 [snip]

Best regards
Peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEI/lox+/gN8KI3u0RAqGiAKCxNZCmZpaTxaHNds6B4LNgzvjBEACggPmH
lE679gXhLoZlrOUDlHYbcX8=
=I0iP
-----END PGP SIGNATURE-----


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