Refreshing the memory on performance:
http://r.789695.n4.nabble.com/reduce-limit-number-of-arguments-in-methods-cbind-td921600.html#a921601
My issue had been resolved by a more careful approach taken by timeSeries.
The other option is wholesale deprecation of S4 ... but I won't start
that conversation with either of you ;-)
Jeff
On Fri, Sep 14, 2012 at 3:00 AM, Martin Maechler
<maech...@stat.math.ethz.ch> wrote:
>>>>>> Martin Morgan <mtmor...@fhcrc.org>
>>>>>> on Wed, 12 Sep 2012 15:23:02 -0700 writes:
>
> > The methods package ?cbind2 includes the instruction to
> > use via methods:::bind_activation(TRUE).
>
> well, "instruction" only if one wants to magically enable its
> use for cbind(), rbind()
>
> > use via methods:::bind_activation(TRUE). This changes the
> > default definition of cbind globally, disrupting proper
> > evaluation in packages not using cbind2.
>
> { really disrupting? I seem to only recall examples of
> performance loss, but that memory is fading.. }
>
> > evaluation in packages not using cbind2. Is cbind2 a
> > hold-over from a time when ... could not be used for
> > dispatch?
>
> Yes, exactly.
>
> As I'm sure you know well, and ?dotMethods explains,
> the ... dispatch was introduced only in R 2.8.0,
> *and* if you read that help page, it is alluded to several times
> that the implementation is still not "perfect" because it
> entails restrictions, and also because its implementation in
> pure R rather than (partially) C.
>
> I had hoped (but not spent work myself, alas!) that there would
> be evolution from there on, but it seems we forgot about it.
>
> > What is a safe way for a package to use cbind2?
>
> to define methods for cbind2 / rbind2, with nice multiple
> dispatch on both arguments, as the 'Matrix' package has been
> doing for many years (long before R 2.8.0) --> Matrix/R/bind.R
>
> And then, instead of "bind_activation",
> Matrix now also defines cBind() & rBind()
> as substitutes for cbind(), rbind(),
> simply as using methods:::cbind() which recursively calls
> cbind2(), rbind2().
>
> This has still the big drawback that cbind() fails on "Matrix"
> matrices {and even with quite an unhelpful error message!},
> and useRs must learn to use cBind() instead....
> not ideal, at all.
>
>
> In an ideal R world,
> 1) the "..." S4 dispatch would be improved and made faster
> 2) that part of Matrix would be rewritten, so that cbind() and rbind()
> would work via '...' dispatch on both "Matrix" matrices and
> all standard R objects (atomic vectors, "matrix", data.frame,...),
> and the use of cBind() and rBind() could be deprecated.
>
> I also have a vague recollection that '2)' was not just a job to
> be done with finite some effort, but rather seemed not easily
> achievable with the current restriction of "..." dispatch
> needing all arguments to be of the same superclass.
> We would have to define
>
> setGeneric("cbind", signature = "...")
> setGeneric("rbind", signature = "...")
>
> setMethod("cbind", "Mnumber", function(..., deparse.level=1) {
> ........
> ........
> })
>
> similarly to what I do in the Rmpfr package,
> and where "Mnumber" is a *large* class union... defined in
> Rmpfr/R/AllClasses.R and if you look in there, you see comments
> with FIXME ... basically the solution was +- ok, but not really
> entirely satisfactory to me.
>
> Still, we maybe should really discuss to have the above two
> setGeneric()s in 'methods', and possibly also some class union /
> superclass definitions there (that other packages could use!) possibly even
> with
> setMethod("cbind", <large-mother-class>,
> function(..., deparse.level=1) {
> ......
> })
> and of course the same with rbind().
>
>
> > This came up in the context of complex package
> > dependencies in Bioconductor, as detailed in this thread
> > (sorry for the html).
>
> > https://stat.ethz.ch/pipermail/bioc-devel/2012-September/003617.html
>
> > --
> > Dr. Martin Morgan Fred Hutchinson Cancer Research Center
> > 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
>
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
