Support open/closed intervals in StaticIntervalTree

[laurisvan]

First of all, thanks for a great library, we appreciate the work you have put into this.

We are using StaticIntervalTree to model time intervals [start,end) and use intervalsContainingPoint and also a bit of intervalsOverlappingInterval. As far as we understand, StaticIntervalTree models all intervals as closed. In our cases, the intervals are always open form the end, so we need to perform extra checks after the function calls.

While the extra checks are not a big problem performance-wise or functionality-wise, I thought this might be useful addition to the library? For our case the intervals are always interpreted the same way, e.g. we do not mix open and close intervals. Thus, it would be sufficient to add the interval interpretation as optional part of function call, like

tree.intervalsContainingPoint(0, { openBegin: false, openEnd: true}) 
tree.intervalsOverlappingInterval([0, 1], { openBegin: false, openEnd: true}) 

Do you see this as something that could belong to the domain of this library? If so, would you accept a contribution?

[Yomguithereal]

Out of curiosity, are your interval considering items with trivial successors/predecessors (like integers) or more like floats/dates?

[laurisvan]

Out of curiosity, are your interval considering items with trivial successors/predecessors (like integers) or more like floats/dates?

Dates definitely, but for the sake of Mnemonist, we convert them to integers (unix timestamps). The times we deal with, are exact.

[Yomguithereal]

Then, if what you need is just conditions about which comparison operators to use in the function bodies, and it does not have a negligible performance impact, I would gladly review a PR on subject @laurisvan. This said, what I don't remember well and could be a little bit weird API wise is that the constructor is not able to consider other intervals than [close, close], but the getting functions can? I am wondering.

[laurisvan]

Sorry for the late reply - we had a pretty hectic release crunch happening. I will try to familiarise with the constructor case and StaticIntervalTree internals. If it is indeed so, I agree that it is better do one thing right than several things half-right.