*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@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]]

