Skip to content

[RsR] function naming for "robust ..."

4 messages · claudio, Valentin Todorov, Martin Maechler

Original
claudio
# 
Ciao Martin,

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

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

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

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

Claudio
Martin Maechler
# 
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).

and robglm() / glmrob()  {taking up Werner's naming suggestion
which I find very worth of consideration -- 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 the name:
    Claudio> roblmwle
    Claudio> robwlelm

Thank you for the interesting and very relevant question!

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

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

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

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

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

Martin
10 days later
Valentin Todorov
# 
Dear All,

after returning home from the Robcla'2006 workshop in Florence (thanks,
Marko), I would like to continue here a discussion that we started with
Martin (in German). We think that more opinions are necessary.

What happens with packages that contribute to robustbase, at least now, in
the early stages?
When, at what stage of maturity of robustbase,  should the contributed code
be removed from the other packages and they have to rely on 'Depends:
robustbase'?

Best regards,
Valentin
Martin Maechler
# 
ValenT> Dear All, after returning home from the Robcla'2006
    ValenT> workshop in Florence (thanks, Marko), I would like
    ValenT> to continue here a discussion that we started with
    ValenT> Martin (in German). We think that more opinions are
    ValenT> necessary.

and we are still waiting...

    ValenT> What happens with packages that contribute to
    ValenT> robustbase, at least now, in the early stages?

    ValenT> When, at what stage of maturity of robustbase,
    ValenT> should the contributed code be removed from the
    ValenT> other packages and they have to rely on 
    ValenT> 'Depends: robustbase'?

In theory, the code that has been moved to robustbase could be
stripped from the other package immediately after a new version
(that contains the "moved functionality") of 'robustbase' is
released to CRAN and available from there both in source and
(MacOSX + Windows) binary formats.

This theory works when people use
   install.packages(...., dependencies = TRUE)
and because in windows (and I think Mac OSX), the menus
"Packages" -> "install packages" uses the ``dependencies = TRUE'' setting.

In practice, I would aim for a more pragmatic solution;
e.g., after the appearance of the new version of robustbase, 
wait for several weeks before stripping the functionality from
your package.  Well actually, as package author, you can do it
immediately in your sources, but only release a new version of
your package to CRAN after a certain amount of time.

Martin

And yes, as Valentin, I am very much interested to hear what
others think...