c()ombining G/IRanges with elementMetadata: feature inquiry/request
1
0
Entering edit mode
@steve-lianoglou-2771
Last seen 22 months ago
United States
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) 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
Cancer Cancer • 1.4k views
ADD COMMENT •
0
Entering edit mode
@michael-lawrence-3846
Last seen 3.0 years ago
United States
On Mon, Feb 7, 2011 at 9:42 AM, Steve Lianoglou < mailinglist.honeypot@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. Also realize that these objects have a "metadata" slot in addition to elementMetadata. Not sure how that is currently combined/handled. 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)) But yea, your idea for 'c' is convenient. Care to submit a patch? 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@r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor > [[alternative HTML version deleted]]
ADD COMMENT •
0
Entering edit mode
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? > 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)? 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 > > -- 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
ADD REPLY •
0
Entering edit mode
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
ADD REPLY •
0
Entering edit mode
On Mon, Feb 7, 2011 at 2:58 PM, Martin Morgan <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=""> wrote: >>> On Mon, Feb 7, 2011 at 9:42 AM, Steve Lianoglou >>> <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? >>> 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) > 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. 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
ADD REPLY •
0
Entering edit mode
On Mon, Feb 7, 2011 at 7:38 PM, Steve Lianoglou < mailinglist.honeypot@gmail.com> wrote: > On Mon, Feb 7, 2011 at 2:58 PM, Martin Morgan <mtmorgan@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@gene.com> wrote: > >>> On Mon, Feb 7, 2011 at 9:42 AM, Steve Lianoglou > >>> <mailinglist.honeypot@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. > > > 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 > [[alternative HTML version deleted]]
ADD REPLY •
0
Entering edit mode
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
ADD REPLY •
0
Entering edit mode
Sorry that this thread went cold, but I'm hoping we can come to some consensus: On Tue, Feb 8, 2011 at 12:56 PM, Martin Morgan <mtmorgan at="" fhcrc.org=""> wrote: [snip] > 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. [/snip] I think my preference would be to have all of these treated the same .. which would mean to error on rbind/c'ing *Ranges with different cols in their elementMetadata, and include an option to drop their elementMetadata when you combine them. I feel like the elementMetadata in IRanges isn't thought of "as important" as the ones for GRanges, but I (myself) don't really differentiate between the two. Also, I think exposing the same functionality like what's in IRanges:::.rbind.elementMetadata so that several such elementMetadata's can be massaged in a manner that allows them to be combined w/o losing their respective info would also be helpful. -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
ADD REPLY •
0
Entering edit mode
On 02/09/2011 01:20 PM, Steve Lianoglou wrote: > Sorry that this thread went cold, but I'm hoping we can come to some consensus: > > On Tue, Feb 8, 2011 at 12:56 PM, Martin Morgan <mtmorgan at="" fhcrc.org=""> wrote: > [snip] >> 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. > [/snip] > > I think my preference would be to have all of these treated the same > .. which would mean to error on rbind/c'ing *Ranges with different > cols in their elementMetadata, and include an option to drop their > elementMetadata when you combine them. ok; I'm also fine (in the rather-see-progress-than-stand-in-the-way) with an arg that mentions elementMetadata rather than values. Martin > > I feel like the elementMetadata in IRanges isn't thought of "as > important" as the ones for GRanges, but I (myself) don't really > differentiate between the two. > > Also, I think exposing the same functionality like what's in > IRanges:::.rbind.elementMetadata so that several such > elementMetadata's can be massaged in a manner that allows them to be > combined w/o losing their respective info would also be helpful. > > -steve > -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793
ADD REPLY •
0
Entering edit mode
On Wed, Feb 9, 2011 at 4:45 PM, Martin Morgan <mtmorgan at="" fhcrc.org=""> wrote: > On 02/09/2011 01:20 PM, Steve Lianoglou wrote: >> Sorry that this thread went cold, but I'm hoping we can come to some consensus: >> >> On Tue, Feb 8, 2011 at 12:56 PM, Martin Morgan <mtmorgan at="" fhcrc.org=""> wrote: >> [snip] >>> 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. >> [/snip] >> >> I think my preference would be to have all of these treated the same >> .. which would mean to error on rbind/c'ing *Ranges with different >> cols in their elementMetadata, and include an option to drop their >> elementMetadata when you combine them. > > ok; I'm also fine (in the rather-see-progress-than-stand-in-the-way) > with an arg that mentions elementMetadata rather than values. Ok. I have a patches for IRanges and GRanges on my machine at home for the `c` methods using the .ignoreElementMetadata argument. It's admittedly quite trivial, but I'll double check it and post back to list when I get back to home base. -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
ADD REPLY •
0
Entering edit mode
Hi, I just wanted to let it be known that I committed a change to the GenomicRanges and IRanges packages to implement what we discussed in this thread: namely, adding an .ignoreElementMetadata argument to the c()-ombine functions for GRanges and IRanges objects. Along with the (simple) code to make that happen, I: (i) updated the corresponding documentation files (IRanges-class.Rd and GRanges-class.Rd) with appropriate descriptions and examples. (ii) Added an extra unit test in the test_IRanges_combine function; and (iii) Added a test_GRanges_combine function to the GenomicRanges package to test for the new functionality, and other (trivial) c()-ombining scenarios. I ran the `R CMD check` for both packages and everything is kosher. Lastly: I just pulled in the latest from trunk in both packages and now notice that there has been a change in the IRanges-setops stuff that fires a warning message about "multiple methods tables found for ... " (union, intersect, and setdiff) when the GenomicRanges package is subsequently loaded. It looks like this is a result of the generics for these methods now takes `...`, so I added the dots to the GenomicRanges:::union,intersect,setdiff functions to sidestep these warnings. The version numbers have been bumped for both. Hope that's OK, -steve On Wed, Feb 9, 2011 at 5:07 PM, Steve Lianoglou <mailinglist.honeypot at="" gmail.com=""> wrote: > On Wed, Feb 9, 2011 at 4:45 PM, Martin Morgan <mtmorgan at="" fhcrc.org=""> wrote: >> On 02/09/2011 01:20 PM, Steve Lianoglou wrote: >>> Sorry that this thread went cold, but I'm hoping we can come to some consensus: >>> >>> On Tue, Feb 8, 2011 at 12:56 PM, Martin Morgan <mtmorgan at="" fhcrc.org=""> wrote: >>> [snip] >>>> 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. >>> [/snip] >>> >>> I think my preference would be to have all of these treated the same >>> .. which would mean to error on rbind/c'ing *Ranges with different >>> cols in their elementMetadata, and include an option to drop their >>> elementMetadata when you combine them. >> >> ok; I'm also fine (in the rather-see-progress-than-stand-in-the- way) >> with an arg that mentions elementMetadata rather than values. > > Ok. I have a patches for IRanges and GRanges on my machine at home for > the `c` methods using the .ignoreElementMetadata argument. > > It's admittedly quite trivial, but I'll double check it and post back > to list when I get back to home base. > > -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 > -- 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
ADD REPLY •

Login before adding your answer.

Similar Posts
Loading Similar Posts
Traffic: 555 users visited in the last hour
Content Search
Users
Tags
Badges
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6