[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