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-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

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. Best wishes Julian