[BioC] c()ombining G/IRanges with elementMetadata: feature inquiry/request

[Martin Morgan]

On 02/07/2011 10:36 AM, Steve Lianoglou wrote:
> On Mon, Feb 7, 2011 at 1:08 PM, Michael Lawrence
> <lawrence.michael at gene.com> wrote:
>>
>> On Mon, Feb 7, 2011 at 9:42 AM, Steve Lianoglou
>> <mailinglist.honeypot at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Would anyone else find it useful to have something like an
>>> ".ignoreValues" argument in the `c`ombine functions for G/IRanges so
>>> that you could easily combine several *Ranges objects that have
>>> different elementMetadata.
>>>
>>> For instance:
>>>
>>> R> library(GenomicRanges)
>>> R> gr.1 <- GRanges('chr1', IRanges(c(1, 10, 30), width=5), '*',
>>> score=rnorm(3))
>>> R> gr.2 <- GRanges('chr2', IRanges(c(20, 50, 100), width=10), '*',
>>> annotation=c('a', 'b', 'c'))
>>>
>>> Now say I want to combine them:
>>>
>>> R> c(gr.1, gr.2)
>>> Error in .Method(..., deparse.level = deparse.level) :
>>>  column names for arg 2 do not match those of first arg
>>>
>>> It makes sense to error on that, since I'm losing information by
>>> combining the two, but suppose that I know I'm going to lose
>>> information but want to combine them anyway, I have to:
>>>
>>> R> values(gr.1) <- NULL
>>> R> values(gr.2) <- NULL
>>> R> c(gr.1, gr.2)
>>>
>>> Which would work, but if I didn't want to lose my elementMetadata, I'd
>>>  make temp vars for gr.1 and gr.2 and set their values() to NULL then
>>> combine the two (three, four, etc.)
>>>
>>> But what if something like this was kosher:
>>>
>>> R> c(gr.1, gr.2, .ignoreValues=TRUE)
>>>
>>
>> Pretty good idea. Might name that parameter .ignoreElementMetadata. Longer,
>> yes, but ignoreValues just sounds too generic.
> 
> I'm fine with either one, but I thought that the `values()`
> function/idiom was introduced after `elementMetadata` came into play
> simply because `elementMetadata` was a bit too cumbersome for
> something that people used often.
> 
> I'm curious what the folks at The Hutch had in mind with respect to
> how they envisioned the `elementMetadata` vs. `values` api to play
> out?

'values' for GenomicRanges.

>> Also realize that these
>> objects have a "metadata" slot in addition to elementMetadata. Not sure how
>> that is currently combined/handled.
> 
> Good point. It looks like the metadata from the first I/GRanges object
> is the only one that's kept, and the rest of the metadata is dropped
> after they are combined. Perhaps something to think about more(?).
> 
>> Another addition could be a function that drops the metadata, just how
>> unname drops the names of something.
>>
>> Then: c(dropMetadata(gr.1), dropMetadata(gr.2))
> 
> I guess it would have to be dropElementMetadata(..) since, `metadata`
> and `elementMetadata` are two different beasts. Alternatively, we can
> have an `unvalue(gr.1)`, which is somehow close to "unname"  :-)
> 
>> But yea, your idea for 'c' is convenient. Care to submit a patch?
> 
> I'd be happy to ... maybe just as soon as we get a green light from
> The Hutch (w.r.t utility and param. name)?

yes sounds good. Is this what 'recursive' is supposed to regulate (with
the current behavior recursive = TRUE, despite the signature?). I'm
recognizing the more-or-less fractal nature of IRanages, and the
multiple elementMetadata locations in GRanges (on ranges(), on values(),
as well as values(ranges()), values(values()), etc.)

Martin

> 
> Thanks,
> -steve
> 
>>
>> Thanks,
>> Michael
>>
>>> and returned the combination of the "range" information of the desired
>>> objects, with a NULL DataFrame for its elementMetadata?
>>>
>>> Looking at the source for the I/GRanges "c" functions, it looks like a
>>> pretty easy change to make, but perhaps it's not worth adding an extra
>>> parameter if others wouldn't find it useful.
>>>
>>> ... just ruminating some ...
>>>
>>> Thanks,
>>>
>>> -steve
>>> --
>>> Steve Lianoglou
>>> Graduate Student: Computational Systems Biology
>>>  | Memorial Sloan-Kettering Cancer Center
>>>  | Weill Medical College of Cornell University
>>> Contact Info: http://cbio.mskcc.org/~lianos/contact
>>>
>>> _______________________________________________
>>> Bioconductor mailing list
>>> Bioconductor at r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/bioconductor
>>> Search the archives:
>>> http://news.gmane.org/gmane.science.biology.informatics.conductor
>>
>>
> 
> 
> 


-- 
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793