[Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Hervé Pagès
hpages at fhcrc.org
Tue Jul 8 17:45:09 CEST 2014
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
More information about the Bioc-devel
mailing list