Skip to content

[RsR] Function names

4 messages · Jean-Christophe BOUETTE, Friedrich Leisch, Martin Maechler

Original
Jean-Christophe BOUETTE
# 
I wasn't in Treviso, but the question was adressed in
http://www.dst.unive.it/rsr/Konis-treviso.pdf
and the answer was glmRob... the same as in Insightful's library.

Or do we need another vote? ;-)

Of course it is not consistent with rlm, but it can be aliased as lmRob.

Joyeux No?l ? tous,
Jean-Christophe.
Friedrich Leisch
# 
> I wasn't in Treviso, but the question was adressed in
  > http://www.dst.unive.it/rsr/Konis-treviso.pdf
  > and the answer was glmRob... the same as in Insightful's library.

  > Or do we need another vote? ;-)

I'm not sure about another vote, but what I am sure about is, that we
need to be *very* careful when using the same names as S-Plus does: If
we use the same name, the functions should be fully compatible, i.e.,
take the same arguments (with same names) and return the same objects.

So the real question is not what name to use, but whether we want a
clone of the S-Plus function or not.

 Pro clone: Code using the function can be used on both S-Plus and R

 Contra clone: The first solution to a given problem is not always the
 best one.

Kjells talk was mostly on recreating the existing S-Plus solution
(based on the possible "code donation" by Insightful). If you remember
the discussion after his talk: there were several people (including
myself) who are not so enthusiastic about cloning the robust library,
because we would make some design decisions differently.

Don't get me wrong: I liked Kjell's talk very much and the Splus
robust library has a lot of good stuff in it, but time goes on, and
people tend to learn.

We are now at a point where we can get it right, and we have the
advantage of existing prototype code, which we can analyze for
strengths and weaknesses. All I'm saying is don't clone without
thinking first. If we use a different name, we can play around and see
what the outcome will be. If we use the same name, users will expect
that at some point in time it does (almost) exactly the same thing as
the S-plus function.

Just my 2c

Best,
Fritz
Friedrich Leisch
# 
>> I wasn't in Treviso,

[...]

  > Kjells talk was mostly on recreating the existing S-Plus solution
  > (based on the possible "code donation" by Insightful). If you remember
  > the discussion after his talk:

Sorry, meant to write "If those of you whe were in Treviso remember
..."

Fritz
Martin Maechler
# 
>> I wasn't in Treviso, but the question was adressed in
    >> http://www.dst.unive.it/rsr/Konis-treviso.pdf
    >> and the answer was glmRob... the same as in Insightful's library.

    >> Or do we need another vote? ;-)

maybe, but Fritz has almost entirely described my own thoughts on this:

    FrL> I'm not sure about another vote, but what I am sure about is, that we
    FrL> need to be *very* careful when using the same names as S-Plus does: If
    FrL> we use the same name, the functions should be fully compatible, i.e.,
    FrL> take the same arguments (with same names) and return the same objects.

    FrL> So the real question is not what name to use, but whether we want a
    FrL> clone of the S-Plus function or not.

    FrL> Pro clone: Code using the function can be used on both S-Plus and R

    FrL> Contra clone: The first solution to a given problem is not always the
    FrL> best one.

    FrL> Kjells talk was mostly on recreating the existing S-Plus solution
    FrL> (based on the possible "code donation" by Insightful). If you remember
    FrL> the discussion after his talk: there were several people (including
    FrL> myself) who are not so enthusiastic about cloning the robust library,
    FrL> because we would make some design decisions differently.

    FrL> Don't get me wrong: I liked Kjell's talk very much and the Splus
    FrL> robust library has a lot of good stuff in it, but time goes on, and
    FrL> people tend to learn.

    FrL> We are now at a point where we can get it right, and we have the
    FrL> advantage of existing prototype code, which we can analyze for
    FrL> strengths and weaknesses. All I'm saying is don't clone without
    FrL> thinking first. If we use a different name, we can play around and see
    FrL> what the outcome will be. If we use the same name, users will expect
    FrL> that at some point in time it does (almost) exactly the same thing as
    FrL> the S-plus function.

As a matter of fact, when talking about the name of the package
'robustbase', I made quite clear that in my opinion, to take the name
'robust' was absolutely wrong, for the same reasons Fritz has used above.

We will be developing functionality partly "from scratch", hopefully
state-of-the-art, and often will differ from what the S-plus
library section 'robust' has, sometimes very much on purpose.
Hence for the same reason that 'robust' was no option to me as
package name, the function names of S-plus 'robust' are not
an option now, in general.
*If* the donation (mentioned by Kjell, cited above by Fritz)
will ever happen {and with a reasonable licence, I'd say},  some
of us might be interested to use that donation for producing a
'robust' package which would probably strive to be a clone of S+
library(robust).
In specific cases (with no particular ones in mind), we
might consider using identical names; this would be even more
true if the above donation happened quickly enough ((and would
be accompanied by a licence similar to (L)GPL. "Only for
academic use" or similar statements would make them unusable for
the 'robustbase' package IMO))

    FrL> Just my 2c
and my 2 Rp. :-)

Martin Maechler, ETH Zurich