Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Hi, On 05/13/2014 01:15 AM, Julian Gehring wrote: 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) Will do. 2) A 'dropMcols' or 'dropmcols' method with signature 'GRanges' that is a wrapper for mcols(x) - NULL How about setMcols(), which is more general than dropmcols()? Thanks, H. 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-boun...@r-project.org [mailto:bioc-devel-boun...@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; ttri...@usc.edu; bioc-devel@r-project.org; bioconduc...@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.mich...@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.tri...@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.gehr...@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]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
On 07/08/2014 11:29 AM, Michael Lawrence wrote: On Tue, Jul 8, 2014 at 10:36 AM, Julian Gehring julian.gehr...@embl.de wrote: Hi Herve, 2) A 'dropMcols' or 'dropmcols' method with signature 'GRanges' that is a wrapper for mcols(x) - NULL How about setMcols(), which is more general than dropmcols()? Do you mean a function like: setMcols - function(x, value = NULL) { mcols(x) = value return(x) } I'd be fine with this. However, some argued before that setting to NULL may be counterintuitive for non-advanced users. Probably best to have both setMcols and dropMcols. OK. Let's go for both. Thanks, H. Best wishes Julian ___ Bioconductor mailing list bioconduc...@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]] ___ Bioc-devel@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: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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-boun...@r-project.org [mailto:bioc-devel-boun...@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; ttri...@usc.edu; bioc-devel@r-project.org; bioconduc...@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.mich...@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.tri...@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.gehr...@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]] ___ Bioc-devel@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
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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.tri...@gmail.comwrote: 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 j...@stowers.org wrote: On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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.gehr...@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.tri...@gmail.comwrote: 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 j...@stowers.org wrote: On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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.gehr...@embl.dewrote: 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.tri...@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 j...@stowers.org wrote: On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@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]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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.gehr...@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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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.tri...@gmail.comwrote: 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.gehr...@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
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.mich...@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.tri...@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.gehr...@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]] ___ Bioc-devel@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: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Wondering, Is it too off the beaten track to expect `mcols-`(x,NULL) to work? hint: it does not -Original Message- From: bioc-devel-boun...@r-project.org [mailto:bioc-devel-boun...@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; ttri...@usc.edu; bioc-devel@r-project.org; bioconduc...@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.mich...@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.tri...@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.gehr...@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]] ___ Bioc-devel@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: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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-boun...@r-project.org [mailto:bioc-devel-boun...@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; ttri...@usc.edu; bioc-devel@r-project.org; bioconduc...@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.mich...@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.tri...@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.gehr...@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]] ___ Bioc-devel@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: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@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: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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-boun...@r-project.org [mailto:bioc-devel-boun...@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; ttri...@usc.edu; bioc-devel@r-project.org; bioconduc...@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.mich...@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.tri...@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.gehr...@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]] ___ Bioc-devel@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: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@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: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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-boun...@r-project.org [mailto:bioc-devel-boun...@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; ttri...@usc.edu; bioc-devel@r-project.org; bioconduc...@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.mich...@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.tri...@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.gehr...@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]] ___ Bioc-devel@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: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@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
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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 j...@stowers.org wrote: On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@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
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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.tri...@gmail.comwrote: 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 j...@stowers.org wrote: On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@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