[RsR] plugins for lmrob()

[Martin Maechler]

Dear "robust R users",

I'm taking up a subject of several months ago,
namely on how to set up some conventions in order to allow 
``plugging'' new methods for  lmrob() {as we in the mean time
came to call it}.

In the discussion below, I ended up proposing that
the ``method functions'' for  lmrob(*, method = <METH>)
should be R functions called   lmrob_<METH>

I still think this is a reasonable scheme, but of course am very
open for reconsideration and better proposals.
In particular, the current lmrob() implementation has the
following "call tree" :
  lmrob()
   |
   \-> lmrob.fit.MM()
        |-> lmrob.S()
        \-> lmrob.MM()

where lmrob.fit.MM() also checks if "lmrob.MM()" converged, and
if not, uses the initial S-estimate.
One could argue that lmrob.MM() really just computes an
M-estimate from a given fixed scale and an initial estimate;
hence it could be renamed to  lmrob_M()  {using the name scheme above}.
OTOH,  lmrob.MM() uses special code to compute robust standard
errors, which---I assume---is only sensible for MM-, not for
arbitrary M- estimates.

Further, from the above desired name changes, we will also have
to change the current  lmrob.control() function to something
like lmrob_MM.control(); and more generally I think we would
want to allow a lmrob_<METH>.control() function for every
lmrob_<METH>() function.  Or does anyone see a better alternative?


The current released version of the "robustbase" package, 0.1-5,
still has no 'method' argument and is ``hardwired'' to use
Matias' implementation of the MM-estimator built on
(Matias+Victor)'s fast-S-estimator.

Before releasing the next version of 'robustbase', which will
have slightly more options for lmrob() anyway, I would like to
go into the indicated direction and allow 'method = "...."' for
lmrob(); keeping the current default of course, but also
1) allowing "S" (or rather "fastS" or "fast S" ?) which would use
   what the currently named lmrob.S() does
2) and  "LTS" (or rather "fast LTS" ?) which would use what
   ltsReg() does.

But it should be possible to implement this in a way such that
e.g., by loading a future version of Claudio's "wle" package, also
something like   lmrob(*, method = "WL")   would work by using
Claudio's function(s).

Your feedback on this is very welcome!

There is also one other issue about current  lmrob(), ltsReg(),
etc on which I will post another message to the list, soon.

Martin

>>>>> "MM" == Martin Maechler <maechler using stat.math.ethz.ch>
>>>>>     on Fri, 20 Jan 2006 22:38:51 +0100 writes:

>>>>> "Claudio" == Claudio Agostinelli <claudio using unive.it>
>>>>>     on Fri, 20 Jan 2006 12:50:43 +0100 (CET) writes:

    Claudio> Ciao Martin, I would like, progressively,
    Claudio> standardize my package 'wle' with the standard of
    Claudio> robustbase. If think, for me, the easy way is to
    Claudio> start with lm function (since you (you, matias and
    Claudio> andreas) are working on roblm).

    MM> and robglm() / glmrob() {taking up Werner's naming
    MM> suggestion which I find very worth of consideration --
    MM> other takers, please.. ?}

    Claudio> Are you thinking of a mechanism, like roblm(*,
    Claudio> method="MM"), in this case there are any way for R
    Claudio> to register "method" from other package once
    Claudio> loaded, so that, for instance, we can have,
    Claudio> automatically, roblm(*, method="WL") for my
    Claudio> function? i.e., for the final user:

    >>> library(robustbase) roblm(*, method="WL") Error: method
    >>> "WL" for "roblm" not found library(wle) # new version of
    >>> the library roblm(*, method="WL") # now it works


    Claudio> Otherwise, what kind of convention should I use for
    Claudio> the name: roblmwle robwlelm

    MM> Thank you for the interesting and very relevant
    MM> question!

    MM> Indeed, "robustbase" itself should not contain all
    MM> possible methods, but rather just the 'base', and
    MM> particular we had agreed for the time being to focus on
    MM> the methodology of the MMY book.

    MM> OTOH, it makes very much sense to allow and encourage
    MM> ``plugins'' from other packages {that will have a
    MM> 'Depends: robustbase'}.

    Claudio> This is a potential problem for extending the
    Claudio> functions to any other new method available in the
    Claudio> future. What is your suggestion?

    MM> well I hope we will converge some time in the future on
    MM> how to do robust linear regression .. :-) {well for p >
    MM> n, we probably still have slack ...}  In any case, I
    MM> think it's a very good idea to allow for plugins, and I
    MM> also agree that we should do this by a naming
    MM> convention.

    MM> In some cases, we (the community of S programmers) have
    MM> used the convention to call the plugin for method <Meth>
    MM> to function <Func> " <Func>.<Meth> " where I think we
    MM> should nowadays most probably use <Func>_<Meth> this
    MM> would give lmrob_wle() or roblm_wle() for your plugin
    MM> function.  But note that we will not only have to agree
    MM> on the naming scheme, but also on exactly what arguments
    MM> the function must accept (it can have further optional
    MM> ones) and what exactly its return value has to look
    MM> like.  But I think it's too early to get into these
    MM> details already now.