Re: [Rd] setMethod("c") [was: setMethod("Summary")]

From: John Chambers <jmc_at_r-project.org>
Date: Thu 07 Sep 2006 - 13:16:22 GMT

A reasonable goal, but for 2.5.x, not 2.4.0, would be to extend a mechanism already in place to allow setMethod() calls for functions in the base package, even though those functions have no directly visible generic function definition. The recent changes to method dispatch should help.

For many primitives (but not all and not for non-primitives) there is already a stored generic function (e.g. getGeneric("+")) which is used when a setMethod call is applied.

We could extend the mechanism to as many functions in base as made sense, including the option of having a different set of formal arguments. For non-primitives, the stored generic would be copied to the base package environment, but only in an R session that was using methods for this function.

Sometime after the dust settles from 2.4.0, I hope to experiment with an arrangement on these lines.

John

Martin Maechler wrote:
>>>>>> "Robin" == Robin Hankin <r.hankin@noc.soton.ac.uk>
>>>>>> on Thu, 7 Sep 2006 12:18:51 +0100 writes:
>>>>>>
>
> Robin> Thank you for this. Minimal self-contained code included below.
> Robin> It is slightly modified from the original because brob objects have two
> Robin> slots, both of which are needed by c().
>
> Robin> [
> Robin> A "brob" obect is represents a real number with two slots: "x" holds
> Robin> its natural
> Robin> logarithm; slot "positive" is Boolean, indicating whether the number
> Robin> is positive.
> Robin> I want this because I need to manipulate numbers up to ~1e20000.
> Robin> The hard bit is addition: log(exp(x) + exp(y)) == x + log1p(exp(y-x))
> Robin> ]
>
> I know and I really like your idea.
> However....
>
> Robin> It seemed to make sense to coerce non-brob arguments to brobs,
> Robin> then make cPair() use cPairOfBrobs() [with coerced arguments] in
> Robin> three of the cases, and c() for the fourth with signature c("ANY",
> Robin> "ANY").
>
> Robin> Now below, JC states that "cWithMethods() _replaces_ the ordinary c
> Robin> (), it's not
> Robin> just a method for it". Does this imply that one cannot set up an R
> Robin> package
> Robin> so that the following code:
>
> Robin> x <- as.brob(1:10)
> Robin> x1 <- c(1,x)
> Robin> x2 <- c(x,1)
>
> Robin> works as expected?
>
> No. There's no way {which does not break much other R code} currently.
> More than two days ago,
> I had told you (and the R-devel readers) that you should look at
> help(cbind2) {and said why}.
> If you *really* look at it, and then
> think about or better study the code underlying
> the methods:::bind_activation(TRUE)
> kludge,
> you will shudder (and run :-) and probably understand that a
> similar kludge for c() is not appropriate.
>
> Robin> Or is there some workaround that would enable me to do this?
>
> well, yes: As John Chambers has tried to say, you have to teach
> your users to use cWithPairs() or c2() or myC() or c.() or any
> reasonable name, but not c().
>
> Martin
>
>

        [[alternative HTML version deleted]]



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri Sep 08 07:12:22 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Thu 07 Sep 2006 - 23:30:07 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.