granges() method for GenomicRanges objects akin to ranges()...
1
0
Entering edit mode
Tim Triche ★ 4.2k
@tim-triche-3561
Last seen 4.2 years ago
United States
I wanted something to extract @ranges from a GRanges object along with its @seqnames, @strand, and @seqinfo. Essentially, everything but the mcols. Does this make sense? Is there a lighter-weight way to avoid any copying in-flight? setMethod("granges", "GRanges", function(x) { GRanges(seqnames=seqnames(x), ranges=ranges(x), strand=strand(x), seqinfo=seqinfo(x)) }) The fact that I'm constructing an entire new GRanges makes me a little queasy... that said, it has turned out to be useful when I just want a short list of locations, as for debugging plotting functions, profile plots, or what have you. Statistics is the grammar of science. Karl Pearson <http: en.wikipedia.org="" wiki="" the_grammar_of_science=""> [[alternative HTML version deleted]]
• 2.4k views
ADD COMMENT •
0
Entering edit mode
@jeff-johnston-6497
Last seen 6.9 years ago
United States
On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche at="" gmail.com=""> wrote: > I wanted something to extract @ranges from a GRanges object along with its > @seqnames, @strand, and @seqinfo. Essentially, everything but the mcols. > > Does this make sense? Is there a lighter-weight way to avoid any copying > in-flight? > > > setMethod("granges", "GRanges", function(x) { > GRanges(seqnames=seqnames(x), > ranges=ranges(x), > strand=strand(x), > seqinfo=seqinfo(x)) > }) > > > The fact that I'm constructing an entire new GRanges makes me a little > queasy... that said, it has turned out to be useful when I just want a > short list of locations, as for debugging plotting functions, profile > plots, or what have you. > Perhaps just this: setMethod("granges", "GRanges", function(x) { mcols(x) <- NULL x })
ADD COMMENT •
0
Entering edit mode
Right, what I was wondering however is whether it's possible not to create or modify the object at all, but rather access only the necessary bits. It seems like a slightly different structure that puts all the location in one place (say @granges) and the metadata in another (as it presently is) might be handy to avoid this hoohah. That's rather a larger change. --t > On May 4, 2014, at 3:23 PM, "Johnston, Jeffrey" <jjj at="" stowers.org=""> wrote: > > >> On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche at="" gmail.com=""> wrote: >> >> I wanted something to extract @ranges from a GRanges object along with its >> @seqnames, @strand, and @seqinfo. Essentially, everything but the mcols. >> >> Does this make sense? Is there a lighter-weight way to avoid any copying >> in-flight? >> >> >> setMethod("granges", "GRanges", function(x) { >> GRanges(seqnames=seqnames(x), >> ranges=ranges(x), >> strand=strand(x), >> seqinfo=seqinfo(x)) >> }) >> >> >> The fact that I'm constructing an entire new GRanges makes me a little >> queasy... that said, it has turned out to be useful when I just want a >> short list of locations, as for debugging plotting functions, profile >> plots, or what have you. > > > Perhaps just this: > > setMethod("granges", "GRanges", function(x) { > mcols(x) <- NULL > x > }) > > >
ADD REPLY •
0
Entering edit mode
Why not just do mcols(gr) <- NULL It's way more obvious than granges(gr). And that should happen virtually instantaneously in R 3.1, regardless of the length. On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. <tim.triche@gmail.com>wrote: > Right, what I was wondering however is whether it's possible not to create > or modify the object at all, but rather access only the necessary bits. > > It seems like a slightly different structure that puts all the location in > one place (say @granges) and the metadata in another (as it presently is) > might be handy to avoid this hoohah. That's rather a larger change. > > --t > > > On May 4, 2014, at 3:23 PM, "Johnston, Jeffrey" <jjj@stowers.org> wrote: > > > > > >> On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche@gmail.com> > wrote: > >> > >> I wanted something to extract @ranges from a GRanges object along with > its > >> @seqnames, @strand, and @seqinfo. Essentially, everything but the > mcols. > >> > >> Does this make sense? Is there a lighter-weight way to avoid any > copying > >> in-flight? > >> > >> > >> setMethod("granges", "GRanges", function(x) { > >> GRanges(seqnames=seqnames(x), > >> ranges=ranges(x), > >> strand=strand(x), > >> seqinfo=seqinfo(x)) > >> }) > >> > >> > >> The fact that I'm constructing an entire new GRanges makes me a little > >> queasy... that said, it has turned out to be useful when I just want a > >> short list of locations, as for debugging plotting functions, profile > >> plots, or what have you. > > > > > > Perhaps just this: > > > > setMethod("granges", "GRanges", function(x) { > > mcols(x) <- NULL > > x > > }) > > > > > > > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]]
ADD REPLY •
0
Entering edit mode
Hi Tim, I was looking for a similar function a while ago, and created the 'grangesPlain' function in 'SomaticSignatures': grangesPlain <- function (x) { mcols(x) = NULL x = as(x, "GRanges") return(x) } It removes the metadata columns, as Michael described. Further, it performs an explicit conversion to a 'GRanges' object - in case that 'x' has a derived class like a 'VRanges'. The main motivation for an extra function is that you can use it inline, e.g resize(sort(grangesPlain(x)), ...) works. It would be great to have such functionality as part of the bioc core. Best wishes Julian On 05.05.2014 01:56, Michael Lawrence wrote: > Why not just do > > mcols(gr) <- NULL > > It's way more obvious than granges(gr). And that should happen virtually > instantaneously in R 3.1, regardless of the length. > > > > > On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. <tim.triche at="" gmail.com="">wrote: > >> Right, what I was wondering however is whether it's possible not to create >> or modify the object at all, but rather access only the necessary bits. >> >> It seems like a slightly different structure that puts all the location in >> one place (say @granges) and the metadata in another (as it presently is) >> might be handy to avoid this hoohah. That's rather a larger change. >> >> --t >> >>> On May 4, 2014, at 3:23 PM, "Johnston, Jeffrey" <jjj at="" stowers.org=""> wrote: >>> >>> >>>> On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche at="" gmail.com=""> >> wrote: >>>> >>>> I wanted something to extract @ranges from a GRanges object along with >> its >>>> @seqnames, @strand, and @seqinfo. Essentially, everything but the >> mcols. >>>> >>>> Does this make sense? Is there a lighter-weight way to avoid any >> copying >>>> in-flight? >>>> >>>> >>>> setMethod("granges", "GRanges", function(x) { >>>> GRanges(seqnames=seqnames(x), >>>> ranges=ranges(x), >>>> strand=strand(x), >>>> seqinfo=seqinfo(x)) >>>> }) >>>> >>>> >>>> The fact that I'm constructing an entire new GRanges makes me a little >>>> queasy... that said, it has turned out to be useful when I just want a >>>> short list of locations, as for debugging plotting functions, profile >>>> plots, or what have you. >>> >>> >>> Perhaps just this: >>> >>> setMethod("granges", "GRanges", function(x) { >>> mcols(x) <- NULL >>> x >>> }) >>> >>> >>> >> >> _______________________________________________ >> Bioc-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel >
ADD REPLY •
0
Entering edit mode
Lovely. Hadn't even thought about the VRanges aspect in a while, but this is essentially the use case I had as well. Thanks! --t > On May 5, 2014, at 1:25 AM, Julian Gehring <julian.gehring at="" embl.de=""> wrote: > > Hi Tim, > > I was looking for a similar function a while ago, and created the 'grangesPlain' function in 'SomaticSignatures': > > grangesPlain <- > function (x) > { > mcols(x) = NULL > x = as(x, "GRanges") > return(x) > } > > It removes the metadata columns, as Michael described. Further, it performs an explicit conversion to a 'GRanges' object - in case that 'x' has a derived class like a 'VRanges'. > > The main motivation for an extra function is that you can use it inline, e.g > > resize(sort(grangesPlain(x)), ...) > > works. It would be great to have such functionality as part of the bioc core. > > Best wishes > Julian > > >> On 05.05.2014 01:56, Michael Lawrence wrote: >> Why not just do >> >> mcols(gr) <- NULL >> >> It's way more obvious than granges(gr). And that should happen virtually >> instantaneously in R 3.1, regardless of the length. >> >> >> >> >> On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. <tim.triche at="" gmail.com="">wrote: >> >>> Right, what I was wondering however is whether it's possible not to create >>> or modify the object at all, but rather access only the necessary bits. >>> >>> It seems like a slightly different structure that puts all the location in >>> one place (say @granges) and the metadata in another (as it presently is) >>> might be handy to avoid this hoohah. That's rather a larger change. >>> >>> --t >>> >>>> On May 4, 2014, at 3:23 PM, "Johnston, Jeffrey" <jjj at="" stowers.org=""> wrote: >>>> >>>> >>>>> On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche at="" gmail.com=""> >>> wrote: >>>>> >>>>> I wanted something to extract @ranges from a GRanges object along with >>> its >>>>> @seqnames, @strand, and @seqinfo. Essentially, everything but the >>> mcols. >>>>> >>>>> Does this make sense? Is there a lighter-weight way to avoid any >>> copying >>>>> in-flight? >>>>> >>>>> >>>>> setMethod("granges", "GRanges", function(x) { >>>>> GRanges(seqnames=seqnames(x), >>>>> ranges=ranges(x), >>>>> strand=strand(x), >>>>> seqinfo=seqinfo(x)) >>>>> }) >>>>> >>>>> >>>>> The fact that I'm constructing an entire new GRanges makes me a little >>>>> queasy... that said, it has turned out to be useful when I just want a >>>>> short list of locations, as for debugging plotting functions, profile >>>>> plots, or what have you. >>>> >>>> >>>> Perhaps just this: >>>> >>>> setMethod("granges", "GRanges", function(x) { >>>> mcols(x) <- NULL >>>> x >>>> }) >>> >>> _______________________________________________ >>> Bioc-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> Bioc-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>
ADD REPLY •
0
Entering edit mode
The in-line usage makes sense. How about dropmcols() or something, at least for removing the mcols? On Mon, May 5, 2014 at 1:25 AM, Julian Gehring <julian.gehring@embl.de>wrote: > Hi Tim, > > I was looking for a similar function a while ago, and created the > 'grangesPlain' function in 'SomaticSignatures': > > grangesPlain <- > function (x) > { > mcols(x) = NULL > x = as(x, "GRanges") > return(x) > } > > It removes the metadata columns, as Michael described. Further, it > performs an explicit conversion to a 'GRanges' object - in case that 'x' > has a derived class like a 'VRanges'. > > The main motivation for an extra function is that you can use it inline, > e.g > > resize(sort(grangesPlain(x)), ...) > > works. It would be great to have such functionality as part of the bioc > core. > > Best wishes > Julian > > > > On 05.05.2014 01:56, Michael Lawrence wrote: > >> Why not just do >> >> mcols(gr) <- NULL >> >> It's way more obvious than granges(gr). And that should happen virtually >> instantaneously in R 3.1, regardless of the length. >> >> >> >> >> On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. <tim.triche@gmail.com>> >wrote: >> >> Right, what I was wondering however is whether it's possible not to >>> create >>> or modify the object at all, but rather access only the necessary bits. >>> >>> It seems like a slightly different structure that puts all the location >>> in >>> one place (say @granges) and the metadata in another (as it presently is) >>> might be handy to avoid this hoohah. That's rather a larger change. >>> >>> --t >>> >>> On May 4, 2014, at 3:23 PM, "Johnston, Jeffrey" <jjj@stowers.org> >>>> wrote: >>>> >>>> >>>> On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche@gmail.com> >>>>> >>>> wrote: >>> >>>> >>>>> I wanted something to extract @ranges from a GRanges object along with >>>>> >>>> its >>> >>>> @seqnames, @strand, and @seqinfo. Essentially, everything but the >>>>> >>>> mcols. >>> >>>> >>>>> Does this make sense? Is there a lighter-weight way to avoid any >>>>> >>>> copying >>> >>>> in-flight? >>>>> >>>>> >>>>> setMethod("granges", "GRanges", function(x) { >>>>> GRanges(seqnames=seqnames(x), >>>>> ranges=ranges(x), >>>>> strand=strand(x), >>>>> seqinfo=seqinfo(x)) >>>>> }) >>>>> >>>>> >>>>> The fact that I'm constructing an entire new GRanges makes me a little >>>>> queasy... that said, it has turned out to be useful when I just want a >>>>> short list of locations, as for debugging plotting functions, profile >>>>> plots, or what have you. >>>>> >>>> >>>> >>>> Perhaps just this: >>>> >>>> setMethod("granges", "GRanges", function(x) { >>>> mcols(x) <- NULL >>>> x >>>> }) >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Bioc-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >>> >> [[alternative HTML version deleted]] >> >> >> _______________________________________________ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> [[alternative HTML version deleted]]
ADD REPLY •
0
Entering edit mode
On 05/05/2014 06:55 AM, Michael Lawrence wrote: > The in-line usage makes sense. How about dropmcols() or something, at least > for removing the mcols? generalize as setMcols, like setNames? setMcols(x, NULL) > > > On Mon, May 5, 2014 at 1:25 AM, Julian Gehring <julian.gehring at="" embl.de="">wrote: > >> Hi Tim, >> >> I was looking for a similar function a while ago, and created the >> 'grangesPlain' function in 'SomaticSignatures': >> >> grangesPlain <- >> function (x) >> { >> mcols(x) = NULL >> x = as(x, "GRanges") >> return(x) >> } >> >> It removes the metadata columns, as Michael described. Further, it >> performs an explicit conversion to a 'GRanges' object - in case that 'x' >> has a derived class like a 'VRanges'. >> >> The main motivation for an extra function is that you can use it inline, >> e.g >> >> resize(sort(grangesPlain(x)), ...) >> >> works. It would be great to have such functionality as part of the bioc >> core. >> >> Best wishes >> Julian >> >> >> >> On 05.05.2014 01:56, Michael Lawrence wrote: >> >>> Why not just do >>> >>> mcols(gr) <- NULL >>> >>> It's way more obvious than granges(gr). And that should happen virtually >>> instantaneously in R 3.1, regardless of the length. >>> >>> >>> >>> >>> On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. <tim.triche at="" gmail.com="">>>> wrote: >>> >>> Right, what I was wondering however is whether it's possible not to >>>> create >>>> or modify the object at all, but rather access only the necessary bits. >>>> >>>> It seems like a slightly different structure that puts all the location >>>> in >>>> one place (say @granges) and the metadata in another (as it presently is) >>>> might be handy to avoid this hoohah. That's rather a larger change. >>>> >>>> --t >>>> >>>> On May 4, 2014, at 3:23 PM, "Johnston, Jeffrey" <jjj at="" stowers.org=""> >>>>> wrote: >>>>> >>>>> >>>>> On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche at="" gmail.com=""> >>>>>> >>>>> wrote: >>>> >>>>> >>>>>> I wanted something to extract @ranges from a GRanges object along with >>>>>> >>>>> its >>>> >>>>> @seqnames, @strand, and @seqinfo. Essentially, everything but the >>>>>> >>>>> mcols. >>>> >>>>> >>>>>> Does this make sense? Is there a lighter-weight way to avoid any >>>>>> >>>>> copying >>>> >>>>> in-flight? >>>>>> >>>>>> >>>>>> setMethod("granges", "GRanges", function(x) { >>>>>> GRanges(seqnames=seqnames(x), >>>>>> ranges=ranges(x), >>>>>> strand=strand(x), >>>>>> seqinfo=seqinfo(x)) >>>>>> }) >>>>>> >>>>>> >>>>>> The fact that I'm constructing an entire new GRanges makes me a little >>>>>> queasy... that said, it has turned out to be useful when I just want a >>>>>> short list of locations, as for debugging plotting functions, profile >>>>>> plots, or what have you. >>>>>> >>>>> >>>>> >>>>> Perhaps just this: >>>>> >>>>> setMethod("granges", "GRanges", function(x) { >>>>> mcols(x) <- NULL >>>>> x >>>>> }) >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Bioc-devel at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>>> >>>> >>> [[alternative HTML version deleted]] >>> >>> >>> _______________________________________________ >>> Bioc-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >>> > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793
ADD REPLY •
0
Entering edit mode
Hi, On 05.05.2014 16:22, Martin Morgan wrote: > generalize as setMcols, like setNames? setMcols(x, NULL) How about Tim's original suggestion, to add a 'granges' method that works on a 'GRanges' input? The current definition granges(x, use.mcols=FALSE, ...) seem suited for this. Best wishes Julian
ADD REPLY •
0
Entering edit mode
That's exactly what I was after -- the generic is already defined, so why not use it? --t > On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at="" embl.de=""> wrote: > > Hi, > >> On 05.05.2014 16:22, Martin Morgan wrote: >> generalize as setMcols, like setNames? setMcols(x, NULL) > > How about Tim's original suggestion, to add a 'granges' method that works on a 'GRanges' input? The current definition > > granges(x, use.mcols=FALSE, ...) > > seem suited for this. > > Best wishes > Julian
ADD REPLY •
0
Entering edit mode
In my opinion, granges() is not very clear as to the intent. The mcols are part of the GRanges, so why would calling granges() drop them? I think we want something similar to unclass(), unname(), etc. This why I suggested dropmcols(). On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche@gmail.com>wrote: > That's exactly what I was after -- the generic is already defined, so why > not use it? > > --t > > > On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring@embl.de> > wrote: > > > > Hi, > > > >> On 05.05.2014 16:22, Martin Morgan wrote: > >> generalize as setMcols, like setNames? setMcols(x, NULL) > > > > How about Tim's original suggestion, to add a 'granges' method that > works on a 'GRanges' input? The current definition > > > > granges(x, use.mcols=FALSE, ...) > > > > seem suited for this. > > > > Best wishes > > Julian > [[alternative HTML version deleted]]
ADD REPLY •
0
Entering edit mode
I agree with Michael on this. I can see why, in some usage cases, granges() is convenient to have with use.mcols=FALSE (which seems to have been added in the latest release). But in my usage of granges(), where I call granges() on objects like SummarizedExperiments and friends, I have been expecting granges() to give me the GRange component of the object. Not a crippled version of the GRange component. This is - to me - very counter intuitive and I wish I had seen this earlier. It is particular frustrating that this default is part of the generic. Best, Kasper On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.michael@gene.com> wrote: > In my opinion, granges() is not very clear as to the intent. The mcols are > part of the GRanges, so why would calling granges() drop them? I think we > want something similar to unclass(), unname(), etc. This why I suggested > dropmcols(). > > > > > On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche@gmail.com> >wrote: > > > That's exactly what I was after -- the generic is already defined, so why > > not use it? > > > > --t > > > > > On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring@embl.de> > > wrote: > > > > > > Hi, > > > > > >> On 05.05.2014 16:22, Martin Morgan wrote: > > >> generalize as setMcols, like setNames? setMcols(x, NULL) > > > > > > How about Tim's original suggestion, to add a 'granges' method that > > works on a 'GRanges' input? The current definition > > > > > > granges(x, use.mcols=FALSE, ...) > > > > > > seem suited for this. > > > > > > Best wishes > > > Julian > > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]]
ADD REPLY •
0
Entering edit mode
Hi, I have no problem using granges() for that. Just to clarify: (a) it would propagate the names() (b) it would drop the metadata() (c) the mcols() would propagate only if 'use.mcols=TRUE' was specified ('use.mcols' is FALSE by default) (d) it would return a GRanges *instance* i.e. input object 'x' would be downgraded to GRanges if it extends GRanges @Kasper: granges() on SummarizedExperiment ignores the 'use.mcols' arg and always propagates the mcols. Alternatively you can use rowData() which also propagates the mcols. granges() is actually just an alias for rowData() on SummarizedExperiment objects. H. On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote: > I agree with Michael on this. > > I can see why, in some usage cases, granges() is convenient to have with > use.mcols=FALSE (which seems to have been added in the latest release). > But in my usage of granges(), where I call granges() on objects like > SummarizedExperiments and friends, I have been expecting granges() to give > me the GRange component of the object. Not a crippled version of the > GRange component. > > This is - to me - very counter intuitive and I wish I had seen this > earlier. It is particular frustrating that this default is part of the > generic. > > Best, > Kasper > > > On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.michael at="" gene.com="">> wrote: > >> In my opinion, granges() is not very clear as to the intent. The mcols are >> part of the GRanges, so why would calling granges() drop them? I think we >> want something similar to unclass(), unname(), etc. This why I suggested >> dropmcols(). >> >> >> >> >> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche at="" gmail.com="">>> wrote: >> >>> That's exactly what I was after -- the generic is already defined, so why >>> not use it? >>> >>> --t >>> >>>> On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at="" embl.de=""> >>> wrote: >>>> >>>> Hi, >>>> >>>>> On 05.05.2014 16:22, Martin Morgan wrote: >>>>> generalize as setMcols, like setNames? setMcols(x, NULL) >>>> >>>> How about Tim's original suggestion, to add a 'granges' method that >>> works on a 'GRanges' input? The current definition >>>> >>>> granges(x, use.mcols=FALSE, ...) >>>> >>>> seem suited for this. >>>> >>>> Best wishes >>>> Julian >>> >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> Bioc-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
ADD REPLY •
0
Entering edit mode
Wondering, Is it too off the beaten track to expect `mcols<-`(x,NULL) to work? hint: it does not >-----Original Message----- >From: bioc-devel-bounces at r-project.org [mailto:bioc-devel-bounces at r-project.org] On Behalf Of Hervé Pagès >Sent: Monday, May 05, 2014 1:28 PM >To: Kasper Daniel Hansen; Michael Lawrence >Cc: Johnston, Jeffrey; ttriche at usc.edu; bioc-devel at r-project.org; bioconductor at r-project.org >Subject: Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()... > >Hi, > >I have no problem using granges() for that. Just to clarify: > (a) it would propagate the names() > (b) it would drop the metadata() > (c) the mcols() would propagate only if 'use.mcols=TRUE' was > specified ('use.mcols' is FALSE by default) > (d) it would return a GRanges *instance* i.e. input object 'x' > would be downgraded to GRanges if it extends GRanges > >@Kasper: granges() on SummarizedExperiment ignores the 'use.mcols' >arg and always propagates the mcols. Alternatively you can use rowData() >which also propagates the mcols. granges() is actually just an alias >for rowData() on SummarizedExperiment objects. > >H. > > >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote: >> I agree with Michael on this. >> >> I can see why, in some usage cases, granges() is convenient to have with >> use.mcols=FALSE (which seems to have been added in the latest release). >> But in my usage of granges(), where I call granges() on objects like >> SummarizedExperiments and friends, I have been expecting granges() to give >> me the GRange component of the object. Not a crippled version of the >> GRange component. >> >> This is - to me - very counter intuitive and I wish I had seen this >> earlier. It is particular frustrating that this default is part of the >> generic. >> >> Best, >> Kasper >> >> >> On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.michael at="" gene.com="">>> wrote: >> >>> In my opinion, granges() is not very clear as to the intent. The mcols are >>> part of the GRanges, so why would calling granges() drop them? I think we >>> want something similar to unclass(), unname(), etc. This why I suggested >>> dropmcols(). >>> >>> >>> >>> >>> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche at="" gmail.com="">>>> wrote: >>> >>>> That's exactly what I was after -- the generic is already defined, so why >>>> not use it? >>>> >>>> --t >>>> >>>>> On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at="" embl.de=""> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>>> On 05.05.2014 16:22, Martin Morgan wrote: >>>>>> generalize as setMcols, like setNames? setMcols(x, NULL) >>>>> >>>>> How about Tim's original suggestion, to add a 'granges' method that >>>> works on a 'GRanges' input? The current definition >>>>> >>>>> granges(x, use.mcols=FALSE, ...) >>>>> >>>>> seem suited for this. >>>>> >>>>> Best wishes >>>>> Julian >>>> >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> Bioc-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> Bioc-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > >-- >Hervé Pagès > >Program in Computational Biology >Division of Public Health Sciences >Fred Hutchinson Cancer Research Center >1100 Fairview Ave. N, M1-B514 >P.O. Box 19024 >Seattle, WA 98109-1024 > >E-mail: hpages at fhcrc.org >Phone: (206) 667-5791 >Fax: (206) 667-1319 > >_______________________________________________ >Bioc-devel at r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/bioc-devel
ADD REPLY •
0
Entering edit mode
Hi Malcolm, On 05/05/2014 01:00 PM, Cook, Malcolm wrote: > Wondering, > > Is it too off the beaten track to expect > > `mcols<-`(x,NULL) > args(`mcols<-`) function (x, ..., value) Arguments after the ellipsis must be named: `mcols<-`(x, value=NULL) Nothing we can do about this. Cheers, H. > > to work? > > hint: it does not > > >-----Original Message----- > >From: bioc-devel-bounces at r-project.org [mailto:bioc-devel- bounces at r-project.org] On Behalf Of Hervé Pagès > >Sent: Monday, May 05, 2014 1:28 PM > >To: Kasper Daniel Hansen; Michael Lawrence > >Cc: Johnston, Jeffrey; ttriche at usc.edu; bioc-devel at r-project.org; bioconductor at r-project.org > >Subject: Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()... > > > >Hi, > > > >I have no problem using granges() for that. Just to clarify: > > (a) it would propagate the names() > > (b) it would drop the metadata() > > (c) the mcols() would propagate only if 'use.mcols=TRUE' was > > specified ('use.mcols' is FALSE by default) > > (d) it would return a GRanges *instance* i.e. input object 'x' > > would be downgraded to GRanges if it extends GRanges > > > >@Kasper: granges() on SummarizedExperiment ignores the 'use.mcols' > >arg and always propagates the mcols. Alternatively you can use rowData() > >which also propagates the mcols. granges() is actually just an alias > >for rowData() on SummarizedExperiment objects. > > > >H. > > > > > >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote: > >> I agree with Michael on this. > >> > >> I can see why, in some usage cases, granges() is convenient to have with > >> use.mcols=FALSE (which seems to have been added in the latest release). > >> But in my usage of granges(), where I call granges() on objects like > >> SummarizedExperiments and friends, I have been expecting granges() to give > >> me the GRange component of the object. Not a crippled version of the > >> GRange component. > >> > >> This is - to me - very counter intuitive and I wish I had seen this > >> earlier. It is particular frustrating that this default is part of the > >> generic. > >> > >> Best, > >> Kasper > >> > >> > >> On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.michael at="" gene.com=""> >>> wrote: > >> > >>> In my opinion, granges() is not very clear as to the intent. The mcols are > >>> part of the GRanges, so why would calling granges() drop them? I think we > >>> want something similar to unclass(), unname(), etc. This why I suggested > >>> dropmcols(). > >>> > >>> > >>> > >>> > >>> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche at="" gmail.com=""> >>>> wrote: > >>> > >>>> That's exactly what I was after -- the generic is already defined, so why > >>>> not use it? > >>>> > >>>> --t > >>>> > >>>>> On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at="" embl.de=""> > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>> On 05.05.2014 16:22, Martin Morgan wrote: > >>>>>> generalize as setMcols, like setNames? setMcols(x, NULL) > >>>>> > >>>>> How about Tim's original suggestion, to add a 'granges' method that > >>>> works on a 'GRanges' input? The current definition > >>>>> > >>>>> granges(x, use.mcols=FALSE, ...) > >>>>> > >>>>> seem suited for this. > >>>>> > >>>>> Best wishes > >>>>> Julian > >>>> > >>> > >>> [[alternative HTML version deleted]] > >>> > >>> _______________________________________________ > >>> Bioc-devel at r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >>> > >> > >> [[alternative HTML version deleted]] > >> > >> _______________________________________________ > >> Bioc-devel at r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> > > > >-- > >Hervé Pagès > > > >Program in Computational Biology > >Division of Public Health Sciences > >Fred Hutchinson Cancer Research Center > >1100 Fairview Ave. N, M1-B514 > >P.O. Box 19024 > >Seattle, WA 98109-1024 > > > >E-mail: hpages at fhcrc.org > >Phone: (206) 667-5791 > >Fax: (206) 667-1319 > > > >_______________________________________________ > >Bioc-devel at r-project.org mailing list > >https://stat.ethz.ch/mailman/listinfo/bioc-devel > -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
ADD REPLY •
0
Entering edit mode
>On 05/05/2014 01:00 PM, Cook, Malcolm wrote: >> Wondering, >> >> Is it too off the beaten track to expect >> >> `mcols<-`(x,NULL) > > > args(`mcols<-`) > function (x, ..., value) > >Arguments after the ellipsis must be named: > > `mcols<-`(x, value=NULL) Herve - Great - of course - so - does this not provide the means requested by the original poster? > >Nothing we can do about this. > >Cheers, >H. > >> >> to work? >> >> hint: it does not >> >> >-----Original Message----- >> >From: bioc-devel-bounces at r-project.org [mailto:bioc-devel- bounces at r-project.org] On Behalf Of Hervé Pagès >> >Sent: Monday, May 05, 2014 1:28 PM >> >To: Kasper Daniel Hansen; Michael Lawrence >> >Cc: Johnston, Jeffrey; ttriche at usc.edu; bioc-devel at r-project.org; bioconductor at r-project.org >> >Subject: Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()... >> > >> >Hi, >> > >> >I have no problem using granges() for that. Just to clarify: >> > (a) it would propagate the names() >> > (b) it would drop the metadata() >> > (c) the mcols() would propagate only if 'use.mcols=TRUE' was >> > specified ('use.mcols' is FALSE by default) >> > (d) it would return a GRanges *instance* i.e. input object 'x' >> > would be downgraded to GRanges if it extends GRanges >> > >> >@Kasper: granges() on SummarizedExperiment ignores the 'use.mcols' >> >arg and always propagates the mcols. Alternatively you can use rowData() >> >which also propagates the mcols. granges() is actually just an alias >> >for rowData() on SummarizedExperiment objects. >> > >> >H. >> > >> > >> >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote: >> >> I agree with Michael on this. >> >> >> >> I can see why, in some usage cases, granges() is convenient to have with >> >> use.mcols=FALSE (which seems to have been added in the latest release). >> >> But in my usage of granges(), where I call granges() on objects like >> >> SummarizedExperiments and friends, I have been expecting granges() to give >> >> me the GRange component of the object. Not a crippled version of the >> >> GRange component. >> >> >> >> This is - to me - very counter intuitive and I wish I had seen this >> >> earlier. It is particular frustrating that this default is part of the >> >> generic. >> >> >> >> Best, >> >> Kasper >> >> >> >> >> >> On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.michael at="" gene.com="">> >>> wrote: >> >> >> >>> In my opinion, granges() is not very clear as to the intent. The mcols are >> >>> part of the GRanges, so why would calling granges() drop them? I think we >> >>> want something similar to unclass(), unname(), etc. This why I suggested >> >>> dropmcols(). >> >>> >> >>> >> >>> >> >>> >> >>> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche at="" gmail.com="">> >>>> wrote: >> >>> >> >>>> That's exactly what I was after -- the generic is already defined, so why >> >>>> not use it? >> >>>> >> >>>> --t >> >>>> >> >>>>> On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at="" embl.de=""> >> >>>> wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>>> On 05.05.2014 16:22, Martin Morgan wrote: >> >>>>>> generalize as setMcols, like setNames? setMcols(x, NULL) >> >>>>> >> >>>>> How about Tim's original suggestion, to add a 'granges' method that >> >>>> works on a 'GRanges' input? The current definition >> >>>>> >> >>>>> granges(x, use.mcols=FALSE, ...) >> >>>>> >> >>>>> seem suited for this. >> >>>>> >> >>>>> Best wishes >> >>>>> Julian >> >>>> >> >>> >> >>> [[alternative HTML version deleted]] >> >>> >> >>> _______________________________________________ >> >>> Bioc-devel at r-project.org mailing list >> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >>> >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> _______________________________________________ >> >> Bioc-devel at r-project.org mailing list >> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> >> > >> >-- >> >Hervé Pagès >> > >> >Program in Computational Biology >> >Division of Public Health Sciences >> >Fred Hutchinson Cancer Research Center >> >1100 Fairview Ave. N, M1-B514 >> >P.O. Box 19024 >> >Seattle, WA 98109-1024 >> > >> >E-mail: hpages at fhcrc.org >> >Phone: (206) 667-5791 >> >Fax: (206) 667-1319 >> > >> >_______________________________________________ >> >Bioc-devel at r-project.org mailing list >> >https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > >-- >Hervé Pagès > >Program in Computational Biology >Division of Public Health Sciences >Fred Hutchinson Cancer Research Center >1100 Fairview Ave. N, M1-B514 >P.O. Box 19024 >Seattle, WA 98109-1024 > >E-mail: hpages at fhcrc.org >Phone: (206) 667-5791 >Fax: (206) 667-1319
ADD REPLY •
0
Entering edit mode
On 05/05/2014 02:12 PM, Cook, Malcolm wrote: >> On 05/05/2014 01:00 PM, Cook, Malcolm wrote: > >> Wondering, > >> > >> Is it too off the beaten track to expect > >> > >> `mcols<-`(x,NULL) > > > > > args(`mcols<-`) > > function (x, ..., value) > > > >Arguments after the ellipsis must be named: > > > > `mcols<-`(x, value=NULL) > > Herve - Great - of course - so - does this not provide the means requested by the original poster? I think Tim also wanted 'x' to be downgraded to a GRanges instance, like Julian's grangesPlain() does. We could use granges() for that. Deciding of an idiom that can be used inline for just dropping the mcols would be good too. `mcols<-`(x, value=NULL) is a little bit tricky, ugly, and error prone as you noticed. These are probably enough reasons for not choosing it as *the* idiom. Its only advantage is that it doesn't introduce a new symbol. H. > > > > >Nothing we can do about this. > > > >Cheers, > >H. > > > >> > >> to work? > >> > >> hint: it does not > >> > >> >-----Original Message----- > >> >From: bioc-devel-bounces at r-project.org [mailto:bioc- devel-bounces at r-project.org] On Behalf Of Hervé Pagès > >> >Sent: Monday, May 05, 2014 1:28 PM > >> >To: Kasper Daniel Hansen; Michael Lawrence > >> >Cc: Johnston, Jeffrey; ttriche at usc.edu; bioc-devel at r-project.org; bioconductor at r-project.org > >> >Subject: Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()... > >> > > >> >Hi, > >> > > >> >I have no problem using granges() for that. Just to clarify: > >> > (a) it would propagate the names() > >> > (b) it would drop the metadata() > >> > (c) the mcols() would propagate only if 'use.mcols=TRUE' was > >> > specified ('use.mcols' is FALSE by default) > >> > (d) it would return a GRanges *instance* i.e. input object 'x' > >> > would be downgraded to GRanges if it extends GRanges > >> > > >> >@Kasper: granges() on SummarizedExperiment ignores the 'use.mcols' > >> >arg and always propagates the mcols. Alternatively you can use rowData() > >> >which also propagates the mcols. granges() is actually just an alias > >> >for rowData() on SummarizedExperiment objects. > >> > > >> >H. > >> > > >> > > >> >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote: > >> >> I agree with Michael on this. > >> >> > >> >> I can see why, in some usage cases, granges() is convenient to have with > >> >> use.mcols=FALSE (which seems to have been added in the latest release). > >> >> But in my usage of granges(), where I call granges() on objects like > >> >> SummarizedExperiments and friends, I have been expecting granges() to give > >> >> me the GRange component of the object. Not a crippled version of the > >> >> GRange component. > >> >> > >> >> This is - to me - very counter intuitive and I wish I had seen this > >> >> earlier. It is particular frustrating that this default is part of the > >> >> generic. > >> >> > >> >> Best, > >> >> Kasper > >> >> > >> >> > >> >> On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.michael at="" gene.com=""> >> >>> wrote: > >> >> > >> >>> In my opinion, granges() is not very clear as to the intent. The mcols are > >> >>> part of the GRanges, so why would calling granges() drop them? I think we > >> >>> want something similar to unclass(), unname(), etc. This why I suggested > >> >>> dropmcols(). > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche at="" gmail.com=""> >> >>>> wrote: > >> >>> > >> >>>> That's exactly what I was after -- the generic is already defined, so why > >> >>>> not use it? > >> >>>> > >> >>>> --t > >> >>>> > >> >>>>> On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at="" embl.de=""> > >> >>>> wrote: > >> >>>>> > >> >>>>> Hi, > >> >>>>> > >> >>>>>> On 05.05.2014 16:22, Martin Morgan wrote: > >> >>>>>> generalize as setMcols, like setNames? setMcols(x, NULL) > >> >>>>> > >> >>>>> How about Tim's original suggestion, to add a 'granges' method that > >> >>>> works on a 'GRanges' input? The current definition > >> >>>>> > >> >>>>> granges(x, use.mcols=FALSE, ...) > >> >>>>> > >> >>>>> seem suited for this. > >> >>>>> > >> >>>>> Best wishes > >> >>>>> Julian > >> >>>> > >> >>> > >> >>> [[alternative HTML version deleted]] > >> >>> > >> >>> _______________________________________________ > >> >>> Bioc-devel at r-project.org mailing list > >> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> >>> > >> >> > >> >> [[alternative HTML version deleted]] > >> >> > >> >> _______________________________________________ > >> >> Bioc-devel at r-project.org mailing list > >> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> >> > >> > > >> >-- > >> >Hervé Pagès > >> > > >> >Program in Computational Biology > >> >Division of Public Health Sciences > >> >Fred Hutchinson Cancer Research Center > >> >1100 Fairview Ave. N, M1-B514 > >> >P.O. Box 19024 > >> >Seattle, WA 98109-1024 > >> > > >> >E-mail: hpages at fhcrc.org > >> >Phone: (206) 667-5791 > >> >Fax: (206) 667-1319 > >> > > >> >_______________________________________________ > >> >Bioc-devel at r-project.org mailing list > >> >https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> > > > >-- > >Hervé Pagès > > > >Program in Computational Biology > >Division of Public Health Sciences > >Fred Hutchinson Cancer Research Center > >1100 Fairview Ave. N, M1-B514 > >P.O. Box 19024 > >Seattle, WA 98109-1024 > > > >E-mail: hpages at fhcrc.org > >Phone: (206) 667-5791 > >Fax: (206) 667-1319 > -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
ADD REPLY •
0
Entering edit mode
Hi, In summary, would it be feasible to add to 'GenomicRanges'? 1) A 'granges(x, use.mcols=FALSE, ...)' method with signature 'GRanges' that converts to a 'GRanges' object and optionally drops the mcols (if 'use.mcols' is TRUE) 2) A 'dropMcols' or 'dropmcols' method with signature 'GRanges' that is a wrapper for mcols(x) <- NULL If I can be of help in providing a patch for this, please let me know. Best wishes Julian On 05.05.2014 23:29, Hervé Pagès wrote: > On 05/05/2014 02:12 PM, Cook, Malcolm wrote: >>> On 05/05/2014 01:00 PM, Cook, Malcolm wrote: >> >> Wondering, >> >> >> >> Is it too off the beaten track to expect >> >> >> >> `mcols<-`(x,NULL) >> > >> > > args(`mcols<-`) >> > function (x, ..., value) >> > >> >Arguments after the ellipsis must be named: >> > >> > `mcols<-`(x, value=NULL) >> >> Herve - Great - of course - so - does this not provide the means >> requested by the original poster? > > I think Tim also wanted 'x' to be downgraded to a GRanges instance, > like Julian's grangesPlain() does. We could use granges() for that. > > Deciding of an idiom that can be used inline for just dropping the > mcols would be good too. `mcols<-`(x, value=NULL) is a little bit > tricky, ugly, and error prone as you noticed. These are probably > enough reasons for not choosing it as *the* idiom. Its only advantage > is that it doesn't introduce a new symbol. > > H. > >> >> > >> >Nothing we can do about this. >> > >> >Cheers, >> >H. >> > >> >> >> >> to work? >> >> >> >> hint: it does not >> >> >> >> >-----Original Message----- >> >> >From: bioc-devel-bounces at r-project.org >> [mailto:bioc-devel-bounces at r-project.org] On Behalf Of Hervé Pagès >> >> >Sent: Monday, May 05, 2014 1:28 PM >> >> >To: Kasper Daniel Hansen; Michael Lawrence >> >> >Cc: Johnston, Jeffrey; ttriche at usc.edu; >> bioc-devel at r-project.org; bioconductor at r-project.org >> >> >Subject: Re: [Bioc-devel] [BioC] granges() method for >> GenomicRanges objects akin to ranges()... >> >> > >> >> >Hi, >> >> > >> >> >I have no problem using granges() for that. Just to clarify: >> >> > (a) it would propagate the names() >> >> > (b) it would drop the metadata() >> >> > (c) the mcols() would propagate only if 'use.mcols=TRUE' was >> >> > specified ('use.mcols' is FALSE by default) >> >> > (d) it would return a GRanges *instance* i.e. input object 'x' >> >> > would be downgraded to GRanges if it extends GRanges >> >> > >> >> >@Kasper: granges() on SummarizedExperiment ignores the >> 'use.mcols' >> >> >arg and always propagates the mcols. Alternatively you can use >> rowData() >> >> >which also propagates the mcols. granges() is actually just an >> alias >> >> >for rowData() on SummarizedExperiment objects. >> >> > >> >> >H. >> >> > >> >> > >> >> >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote: >> >> >> I agree with Michael on this. >> >> >> >> >> >> I can see why, in some usage cases, granges() is convenient >> to have with >> >> >> use.mcols=FALSE (which seems to have been added in the >> latest release). >> >> >> But in my usage of granges(), where I call granges() on >> objects like >> >> >> SummarizedExperiments and friends, I have been expecting >> granges() to give >> >> >> me the GRange component of the object. Not a crippled >> version of the >> >> >> GRange component. >> >> >> >> >> >> This is - to me - very counter intuitive and I wish I had >> seen this >> >> >> earlier. It is particular frustrating that this default is >> part of the >> >> >> generic. >> >> >> >> >> >> Best, >> >> >> Kasper >> >> >> >> >> >> >> >> >> On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence >> <lawrence.michael at="" gene.com="">> >> >>> wrote: >> >> >> >> >> >>> In my opinion, granges() is not very clear as to the >> intent. The mcols are >> >> >>> part of the GRanges, so why would calling granges() drop >> them? I think we >> >> >>> want something similar to unclass(), unname(), etc. This >> why I suggested >> >> >>> dropmcols(). >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. >> <tim.triche at="" gmail.com="">> >> >>>> wrote: >> >> >>> >> >> >>>> That's exactly what I was after -- the generic is already >> defined, so why >> >> >>>> not use it? >> >> >>>> >> >> >>>> --t >> >> >>>> >> >> >>>>> On May 5, 2014, at 7:42 AM, Julian Gehring >> <julian.gehring at="" embl.de=""> >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> Hi, >> >> >>>>> >> >> >>>>>> On 05.05.2014 16:22, Martin Morgan wrote: >> >> >>>>>> generalize as setMcols, like setNames? setMcols(x, NULL) >> >> >>>>> >> >> >>>>> How about Tim's original suggestion, to add a 'granges' >> method that >> >> >>>> works on a 'GRanges' input? The current definition >> >> >>>>> >> >> >>>>> granges(x, use.mcols=FALSE, ...) >> >> >>>>> >> >> >>>>> seem suited for this. >> >> >>>>> >> >> >>>>> Best wishes >> >> >>>>> Julian >> >> >>>> >> >> >>> >> >> >>> [[alternative HTML version deleted]] >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Bioc-devel at r-project.org mailing list >> >> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> >>> >> >> >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> >> >> _______________________________________________ >> >> >> Bioc-devel at r-project.org mailing list >> >> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> >> >> >> > >> >> >-- >> >> >Hervé Pagès >> >> > >> >> >Program in Computational Biology >> >> >Division of Public Health Sciences >> >> >Fred Hutchinson Cancer Research Center >> >> >1100 Fairview Ave. N, M1-B514 >> >> >P.O. Box 19024 >> >> >Seattle, WA 98109-1024 >> >> > >> >> >E-mail: hpages at fhcrc.org >> >> >Phone: (206) 667-5791 >> >> >Fax: (206) 667-1319 >> >> > >> >> >_______________________________________________ >> >> >Bioc-devel at r-project.org mailing list >> >> >https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> >> > >> >-- >> >Hervé Pagès >> > >> >Program in Computational Biology >> >Division of Public Health Sciences >> >Fred Hutchinson Cancer Research Center >> >1100 Fairview Ave. N, M1-B514 >> >P.O. Box 19024 >> >Seattle, WA 98109-1024 >> > >> >E-mail: hpages at fhcrc.org >> >Phone: (206) 667-5791 >> >Fax: (206) 667-1319 >> >
ADD REPLY •

Login before adding your answer.

Similar Posts
Loading Similar Posts
Traffic: 584 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