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

Martin Morgan mtmorgan at fhcrc.org
Tue Feb 8 18:56:29 CET 2011


On 02/07/2011 10:16 PM, Michael Lawrence wrote:
> 
> 
> On Mon, Feb 7, 2011 at 7:38 PM, Steve Lianoglou
> <mailinglist.honeypot at gmail.com <mailto:mailinglist.honeypot at gmail.com>>
> wrote:
> 
>     On Mon, Feb 7, 2011 at 2:58 PM, Martin Morgan <mtmorgan at fhcrc.org
>     <mailto:mtmorgan at fhcrc.org>> wrote:
>     > 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 <mailto:lawrence.michael at gene.com>> wrote:
>     >>> On Mon, Feb 7, 2011 at 9:42 AM, Steve Lianoglou
>     >>> <mailinglist.honeypot at gmail.com
>     <mailto:mailinglist.honeypot at gmail.com>> wrote:
>     [snip]
>     >> 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.
> 
>     Ok ... obviously it's your decision to make, but isn't it a bit
>     confusing to settle on values() for GenomicRanges objects and
>     elementMetadata() for IRanges when both "things" represent the same
>     "thing"? What's the motivation for that?
> 
> 
> Although IRanges defines 'values' as a synonym for 'elementMetadata', in
> my opinion elementMetadata is the preferred term. The term 'values' is
> just too generic to work in general. For example, if one has an
> IntegerList, what are the values? The elements or the element metadata?
> What would a naive user think?
> 
> The purpose of GenomicRanges was to annotate a sequence of ranges with
> chromosome, strand, and other data. Since the purpose was annotation,
> values() might be easier to interpret? The values are certainly still
> metadata.. on the elements. The only good thing about values vs.
> elementMetadata is that it's shorter. If the `$` method were supported
> on GenomicRanges, it wouldn't matter nearly as much.
>  
> 
>     >>> 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.
> 
>     Given the values vs. elementMetadata thing above, what should the
>     appropriate name for the parameter be that we're talking about here?
> 
>     Would the c,GenomicRanges function then have a different name for this
>     parameter (.ignoreValues) as compared and to the c,IRanges(or anything
>     else) (.ignoreElementMetadata)?
> 
>     > Is this what 'recursive' is supposed to regulate (with
>     > the current behavior recursive = TRUE, despite the signature?).
> 
>     I'm not sure. I'm having a hard time imagining how recursive=TRUE vs.
>     FALSE would actually behave in the c()-context.
> 
>     Maybe it would make more sense to check for it to be !missing then
>     give a warning telling the user it's not being handled, eg:
> 
>     if (!missing(recursive)) {
>      warning("`recursive` parameter is ignored ...")
>     }
> 
>     (or some such)
> 
> 
> Yea, that's generally what's done. GenomicRanges is a flat structure, so
> recursive has no meaning. Sure, it is composed of slots, but it's
> non-recursive.

just trying not to get stuck on values / elementMetadata. what about
append / rbind, thinking either that append works w/out element
metadata, or that c does and rbind (in the GRanges-are-row-indicies on
values() interpretation; not suitable for IRanges?) / append tries to do
something with element metadata.

Martin

>  
> 
>      
> 
>     > 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.)
> 
>     I never thought about the values() of the ranges() of a GenomicRanges
>     object actually ...
> 
>     While we're at it, I guess there should be a "values" method defined
>     in GenomicRanges that just aliases its elementMetadata() function:
> 
>     setMethod("values", "GenomicRanges", function(x, ...)
>     elementMetadata(x, ...)
> 
>     since elementMetadata,GenomicRanges does some `rownames` bookkeeping
>     before it passes down to the elementMetadata,Sequence method.
> 
> 
> This is exactly what the "values" method for "Sequence" does, as defined
> in IRanges.
>  
> 
>     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
>     <http://cbio.mskcc.org/%7Elianos/contact>
> 
> 


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

Location: M1-B861
Telephone: 206 667-2793



More information about the Bioconductor mailing list