Skip to content

dots for sample --> "implicitGeneric"

2 messages · Martin Maechler, Claudia Beleites

Original
Martin Maechler
# 
CB> Dear R-Developers,
    CB> could 'sample' gain a ... argument?

As you may know, adding '...' also has drawbacks,
most notably that you lose automatic checking of correctly
specified argument names (when the function is called).

OTOH, R has now (since 2.9.0)  had sample.int() as a fast and "robust"
alternative.

    CB> As a convenience function, I added a sample Method to my hyperSpec 
    CB> class. This function however has a flag indicating whether the results 
    CB> should be returned directly as a hyperSpec object or rather as indices 
    CB> that give a random sample.

    CB> For the moment, I use SetGeneric to add the dots argument, but this of 
    CB> course gives a warning that the base function sample is overwritten (and 
    CB> my colleagues are almost as scared of warnings as of errors...)

and they are not the only ones ... 

For a while now, we have (in 'methods') the possibility to make
functions "implicit generic",  see  ?implicitGeneric ,
exactly for purposes like (I think)  you have here
( and notably to ensure that if *different* packages do this,
  they get "compatible" versions of the generic,
  and hence all the different method definitions will be
  "attached" to the same generic )

Namely, you'd want to define S4 methods (and hence make 'sample' an S4 generic)
with "new" arguments in your package.

So, yes, I now have added 'sample' to the list of functions
that we make implicitGeneric in R.
--> Get a version of R-devel, (svn revision >= 51202)
and try the following:
[1] "foo"
Restoring the implicit generic function for ?sample? from package ?base?
    into package ?.GlobalEnv?; the generic differs from the default conversion (Formal arguments differ: (x, size, replace, prob), (x, size, replace, prob, ...))
Creating a new generic function for "sample" in ".GlobalEnv"
[1] "sample"
[1] "sample(<foo>, myArg=64)\n"


Best regards,
Martin Maechler, ETH Zurich


    CB> Thanks,
    CB> Claudia

    CB> -- 
    CB> Claudia Beleites
    CB> Dipartimento dei Materiali e delle Risorse Naturali
    CB> Universit? degli Studi di Trieste
    CB> Via Valerio 2
    CB> I-34127 Trieste
    CB> ITALY
Claudia Beleites
# 
Dear Martin,
Martin Maechler wrote:
Yes, I'm aware of that - and was silently wondering whether one could do 
something against it (besides having nicely behaved functions without ... at the 
end of the call chain).
Yes.
I had a quick thought whether I should do
sample (my.object) => new object with a subset of my.object's spectra
and
sample.int (my.object) => indices for use with my.object
I decided that this is bad, as I would expect that a function somefun.int does 
*expect* rather than *return* the integer.

The other thought was to have an additional function
isample that returns indices. Which after rethinking seems the right thing to do.

However this doesn't solve the implicitGeneric problem: if the object is 
returned I'd like to allow users to pass short messages that end up in the 
object's "logbook".
But this can easily be postponed until R 2.11 is released and sample has the 
implicit generic also for "normal" users (= my colleagues who already complain 
if I ask them to update their R to the official release).
Yes, thank you - that's what I really wanted!
I'll do my "homework" and reread the chaper in Chambers' book.
Exactly.
Thanks a lot.
Wonderful. Works like a charm. Thanks a lot.

Thanks for your kind help,

Claudia