[Bioc-devel] RFC: IntervalTrees for GRanges objects

[Hector Corrada Bravo]

Yep, I didn't comment on that, but I agree that abstracting how
GRanges stores ranges would make this more elegant. Right now
ranges(GRanges) is specified to be of IRanges class instead of the
abstract Ranges class.

If it were the latter then GIntervalTree can be a subclass of
GenomicRanges, in a similar way that IntervalTree is a subclass of
Ranges.

On Wed, Apr 3, 2013 at 12:23 PM, Michael Lawrence
<lawrence.michael at gene.com> wrote:
> Hi Hector,
>
> That's interesting, thanks for passing this along. I'm still wishing that
> somehow GRanges itself could abstract the way it stores ranges. I know that
> Herve/Patrick had some reasons for depending specifically on GRanges. One
> reason was probably convenience at the C level, but it wouldn't be hard to
> create a Ranges abstraction at the C level, as well.
>
> Michael
>
>
>
> On Tue, Apr 2, 2013 at 5:40 PM, Hector Corrada Bravo <hcorrada at gmail.com>
> wrote:
>>
>> Hello bioc-develers,
>>
>> I'm writing an application where lots findOverlap calls are made on
>> static GRanges objects. For IRanges we can create persistent
>> IntervalTree objects that would serve the multiple overlap query
>> use-case. There is no equivalent for GenomicRanges objects, so I'm
>> proposing an implementation for this.
>>
>> Please check
>> http://github.com/hcorrada/GenomicIntervalTree
>>
>> There's a first cut implementation there you can test by installing
>> this skeleton package. E.g,
>>
>> > library(devtools)
>> > install_github("GenomicIntervalTree", username="hcorrada", subdir="pkg")
>> > library(GenomicIntervalTree)
>>
>> Let me know what you think.
>>
>> Cheers,
>> Hector
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>