[RsR] covrob --- some OOP-comments

Heinrich Fritz e0325693 @end|ng |rom @tud4@tuw|en@@c@@t
Sun Mar 26 23:34:57 CEST 2006


Dear Peter, Valentin and Martin,

Thanks for your comments on the package covrob!!

Your suggestions are very constructive, we already updated the 
implementation according to your remarks. The new version is now online 
at

http://www.statistik.tuwien.ac.at/rsr/groups/mva.html

with the following changes:

(*) The class has been renamed (from covStruct) to cov

	Further there is a covR - class available (derived from cov). At the 
moment it does not include any other slots.

(*) S3 - S4 mix:
This problem has been resolved.

The following functions are still available for the (S4) cov object:

plot <taking one or two objects>
print
summary

(*) I have improved the argument - passing.

The reason why I chose to use the ... implementation was the following:

Some cov estimation methods (covOGK) do not take a "control" - argument 
for passing input arguments. The covrob wrapper should work with as 
many existing cov - methods as possible (without changing those 
methods!!!) and in this case passing arguments is only possible by the 
... syntax. However if a cov - method (like covMest or covMcd) takes a 
control - argument for passing other arguments this control structure 
will be passed anyway.

I have now explicitly added the control - argument to covrob.

My suggestion for passing arguments via a control - structure is to use 
a simple list. In my opinion it is not really comfortable for users to 
instantiate a new class for (almost) every single call of covrob.

Further the only disadvantage by using a simple list is, that since no 
slots (and slot - data types) are defined the user could pass anything 
via the control structure. This has to be caught anyway because it is 
always possible to call an function with invalid arguments (e.g. cov 
(testdata, alpha = "asd"))

So the now implemented solution would work the following way:

covrob (testdata, method = "<estimator>", control = list (argument1 = 
.., argument2 = ..))

or this would work too:

covrob (testdata, method = "<estimator>", argument1 = .., argument2 = ..)

The problem with the second version is, that there may be naming 
problems (as mentioned by XX)- (e.g. a cov - estimator takes an 
argument called "method") but this is only for assuring, that covrob 
works with existing cov estimators which do not take a control - 
structure. (e.g. the author does not know anything about the covrob - 
package.)

(*) Further I have implemented a function for applying the control - 
object to the input arguments..

function (x, a1 = <default 4 a1>, a2 = <default 4 a2>, a3 = <default 4 
a3>, <further arguments>, control)
{
	if (!missing (control))
	{
		if (!is.null(control$a1))		a1 = control$a1
		if (!is.null(control$a2))		a2 = control$a2
		if (!is.null(control$a3))		a3 = control$a3
		# other arguments..
	}
	....
}

would then be

function (x, a1 = <default 4 a1>, a2 = <default 4 a2>, a3 = <default 4 
a3>, <further arguments>, control)
{
	if (!missing (control))
		ParseControlStructure (control)
	....
}

This was possible by the (very excellent) code from Peter

>> eval.parent(substitute( object using distance <- distanceValues ))

I don't know if it is the common way of passing arguments by reference, 
but this is very powerful!

The advantage of this approach is that the control - structure does not 
need to contain all arguments which can be passed to the function but 
only those which should really be set.

An example of the function ParseControlStructure can be found in the 
corresponding help
file.

(*) Accesssor functions

I have implemented several accessor functions:

cov
cor			returning (first time: calculating) the correlation matrix
center
method		returning the name of the estimator..
details		returning the whole output - object of the cov - estimation method
datadim
mah			mahalanobis distances.
mah.wt		only calculating the mah - weights (as Martin Maechler proposed.)

These are generic functions - I hope this is the way it was intended!

(*) Mahalanobis distances.

They are now taken from the output object of the cov - method (if available)

(*)

* from Martin Maechler: *
>
> 1. In general I think we should have a bit less "optional"
>   parts; in particular, top of page 4, I think one could
>   require 'method'.>    require 'method'.

Again: We wanted to be compatible to as many (existing) covariance 
estimation methods as possible. I don't believe that it is very 
expensive to check whether a method-string has been returned or not.

(*)

> '3.1  arguments of covrob()' :
>   x: should be a numeric matrix  *or a data frame*

This has been implemented anyway. It was not described correctly in the pdf.

(*)

* from Valentin Todorov *

> - What happens with the user of, for example covMcd() when it begins to
> return an S4 class "Mcd" instead of the current S3 "mcd". Of course these
> that just use print/plot/summary will not notice the change, but what about
> these that use the returned object within their programs? This is actually a
> general question on compatibility.

This was exactly the reason why we chose the wrapping - solution. It 
should work (and generate S4 output) using available functions because 
we assumed that it is impossible to change the output of functions 
which are already published and in use by others. Code, relying on 
these functions to produce the output described in the help - pages, 
would not work anymore. Everybody using these functions would have to 
change his code. So I think the wrapping - version is the solution with 
the fewest compatibility problems.

(*) I've kicked the classical estimation.
Instead I've implemented an estimator "cov.classic"

best regards,

Heinrich




More information about the R-SIG-Robust mailing list