jgblight / im_interval_tree Goto Github PK

The bounds for T in Interval are Ord + Clone, and Bound<T> is Clone if T: Clone.

I'm wondering why did you wrap with Rc. Did you need to use a type T that it is very expensive to clone? If not, which is what I would expect, is there any chance that we could remove it? Even when T would be expensive to clone, I believe the user could use an Rc/Arc her/himself without the library forcing any specific shared reference. WDYT?

Thank you very much in advance for your clarifications ;-)

Hi, I need to use this data structure in a multi-thread context, which requires using Arc instead of Rc so it is Send.

I was thinking that it would be possible to support both cases using a feature. By default it would use Rc, but when the feature was specified it would use an Arc.

I'm willing to contribute it myself, I would just need some guidance from you to choose a proper name for the feature and review the PR.

Looking forward from hearing from you ;-)

Hi, I found this library very useful for my use case. I need to use it to store musical notes, where every note has a start and a duration, then I can query all the notes in a certain interval. But a note has several other properties a part from the interval bounds, such as the key or the velocity, that I would like also to be stored and retrieved.

There are different approaches available:

1. Add an optional field to the existing Interval type that stores arbitrary data associated to that interval. It would require a new generic type D that could have the type () assigned by default.
2. Add a new type parameter D to the IntervalTree to specify the type of the data. Any type used for D should implement the trait ToInterval that would provide an Interval. By default it could use the existing Interval type as D (so we don't break backward compatibility), but people could also create their custom ones, like in my example a Note type.

I'm more inclined to use the approach number 2, but would like to have your feedback. In the meantime, I have prepared a proof of concept that runs the tests untouched (which demonstrates that it keeps backward compatibility for existing code). See this branch.

I can implement this myself, and would only require your help for feedback and review.

Thanks for sharing this! I used this library as the basis for implementing an immutable interval tree in OCaml: dgllghr/interval-map.

I noticed that interval comparison treats an exclusive lower bounds as being less than inclusive lower bounds when the magnitude of the bound is equal. It also treats exclusive upper bounds as being greater than inclusive upper bounds when the magnitude of the bound is equal.

This was counter-intuitive for me. I would have expected the opposite in those situations (e.g. an inclusive lower bound is less than an exclusive lower bound when the magnitude of the bound is equal). If this is intended behavior, I'm interested to understand so I don't implement something incorrectly in my library. If it's not intended, I can put out a PR to change the behavior in this library.