Hi Martin, I've updated the gist in light of your very helpful feedback at https://gist.github.com/PeteHaitch/8993b096cfa7ccd08c13 (the exact revision at the time of writing is https://gist.github.com/PeteHaitch/8993b096cfa7ccd08c13/375f39835b1855cf3b019f8fcaa65768475fc658). There are still some design choices on which I would appreciate some advice, as discussed in the link.
Thanks, Pete On 16 October 2015 at 07:26, Peter Hickey <[email protected]> wrote: > Thanks for your feedback, Martin. I'll have a go at re-implementing > this and get back to the list next week. > > Cheers, > Pete > > On 16 October 2015 at 05:20, Morgan, Martin > <[email protected]> wrote: >> Hi Pete -- looks like a good idea. >> >> I think the generic could be adjusted to pass named (not x, y) args to >> methods, rather than trying (incorrectly) to combine them. I don't think the >> inefficiency of recursion is a particular concern, because it is not like >> hundreds (or even tens) of objects are typically being combined. >> >> combine() takes the approach of implementing methods for each component -- >> so I guess DataFrame, GRanges, GRangesList, SimpleList (for the assays, >> which are matrix, which are already combine()-able). >> >> Any interest in re-implementing your code along these lines (as methods on >> the building blocks)? Some guidance might come from selectMethod("combine", >> c("data.frame", "data.frame")). >> >> FWIW -- >> >> stop(paste0()) is just stop(), which accepts multiple arguments and pastes >> them together without a separator. >> >> x@NAMES is names(), as in names(GRanges("chr1", IRanges(1, 10, names="A"))) >> >> ?elementMetadata says "Alternatives to 'mcols' functions. Their [i.e., >> elementMetadata] use is discouraged." >> >> >>> -----Original Message----- >>> From: Bioc-devel [mailto:[email protected]] On Behalf Of >>> Peter Hickey >>> Sent: Wednesday, October 14, 2015 9:52 PM >>> To: [email protected] >>> Subject: [Bioc-devel] A method for combining SummarizedExperiment >>> objects >>> >>> I often find myself with multiple `SE` objects (I'm using `SE` as a >>> shorthand for >>> the `SummarizedExperiment0` and `RangedSummarizedExeriment` classes), >>> each with different samples but possibly non-overlapping features/ranges. >>> Currently, it is difficult to combine these objects; `rbind()` can only >>> combine >>> objects with the same samples but different features/ranges and `cbind()` >>> can only combine objects with the same features/ranges but different >>> samples. I think it would be useful to have a "combine" method for `SE` >>> objects that handles the situation where each object has different samples >>> but with possibly non-overlapping features/ranges. >>> >>> I've written a first pass at a method to do this at >>> https://gist.github.com/PeteHaitch/8993b096cfa7ccd08c13. >>> Is this a method other people find themselves in need of and, if so, might >>> we >>> add something like this to the SummarizedExperiment package? As noted in >>> the gist, there's a few things I'd like to address to make it more robust >>> and >>> complete (probably some optimisations too). >>> >>> Cheers, >>> Pete >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> [email protected] mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> >> This email message may contain legally privileged and/or confidential >> information. If you are not the intended recipient(s), or the employee or >> agent responsible for the delivery of this message to the intended >> recipient(s), you are hereby notified that any disclosure, copying, >> distribution, or use of this email message is prohibited. If you have >> received this message in error, please notify the sender immediately by >> e-mail and delete this email message from your computer. Thank you. _______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
