[Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Martin Morgan
mtmorgan at fhcrc.org
Mon May 5 16:22:30 CEST 2014
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
More information about the Bioc-devel
mailing list