[BioC] [Bioc-devel] granges() method for GenomicRanges objects akin to ranges()...
Cook, Malcolm
MEC at stowers.org
Mon May 5 22:00:17 CEST 2014
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
More information about the Bioconductor
mailing list