[Rd] dots for sample --> "implicitGeneric"

Claudia Beleites cbeleites at units.it
Thu Mar 4 15:59:32 CET 2010

Dear Martin,

Martin Maechler wrote:
>>>>>> "CB" == Claudia Beleites <cbeleites at units.it>
>>>>>>     on Sun, 28 Feb 2010 19:31:42 +0100 writes:
>     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).
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).

> OTOH, R has now (since 2.9.0)  had sample.int() as a fast and "robust"
> alternative.
I had a quick thought whether I should do
sample (my.object) => new object with a subset of my.object's spectra
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).

>     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 )

Yes, thank you - that's what I really wanted!
I'll do my "homework" and reread the chaper in Chambers' book.

> 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.
Thanks a lot.

> --> Get a version of R-devel, (svn revision >= 51202)
> and try the following:
>> setClass("foo", contains="vector")
> [1] "foo"
>> setMethod("sample", "foo", function(x, size, myArg, ...) sprintf("sample(<foo>, myArg=%s)\n",myArg))
> 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"
>> sample(new("foo"), myArg = 64)
> [1] "sample(<foo>, myArg=64)\n"
Wonderful. Works like a charm. Thanks a lot.

Thanks for your kind help,


> 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
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

Claudia Beleites
Dipartimento dei Materiali e delle Risorse Naturali
Università degli Studi di Trieste
Via Alfonso Valerio 6/a
I-34127 Trieste

phone: +39 0 40 5 58-37 68
email: cbeleites at units.it

More information about the R-devel mailing list