[Bioc-devel] IntervalTree and Genomic Ranges

Thanks Michael,

It has made significant difference for our visualization project. I would
like to merge this into svn asap. Can I get a ruling from the rest of the
core group? Please let me know if/when/how to proceed.

Cheers,
Hector


On Wed, May 22, 2013 at 1:00 PM, Michael Lawrence <lawrence.michael at gene.com

wrote:

*Added bioc-devel; hope you don't mind*

Hector,

This is great stuff. The overall design is on the right track. As you
said, there's a bit of cleaning to do, but I think we should merge this
into svn and work the rest out from there. This will really benefit
performance, especially for visualization. Of course, I can't speak for the
others.

Michael



On Tue, May 21, 2013 at 11:52 AM, Hector Corrada Bravo <
hcorrada at umiacs.umd.edu> wrote:

Since the semester is over I finally finished this...

Recall that I wanted a persistent set of IntervalTrees for GRanges
objects for repeated querying. (The application is this:
http://epiviz.cbcb.umd.edu/help/?page_id=62 which I hope to get out
soon). Folding this into IRanges and GenomicRanges would make our life
easier come installation time.

I've implemented class 'IntervalForest' within IRanges following
Michael's suggestion of storing this as an array of rbTree on the C side.
I've implemented findOverlaps that operates with this array in C. There is
code duplication in IntervalTree.c that could be reduced but that's if this
makes it into the package.

I've also implemented a 'GIntervalTree' that uses 'IntervalForest'
underneath. findOverlaps-GenomicRanges-GIntervalTree-method is implemented
for this class. I didn't touch the existing
findOverlaps-GenomicRanges-GenomicRanges-method.

You can pull these here:
http://github.com/hcorrada/IRanges
http://github.com/hcorrada/GenomicRanges

These track the devel branch of the two packages. Let me know the best
way to propagate to svn if you guys want this. It needs documentation, but
I'll add that once implementation is settled.

Kasper, I'm not sure if this would help with the 'too many seqlevels'
problem but I'd be curious to know if you try it.

Cheers,
Hector

	[[alternative HTML version deleted]]