split_interval_map usage, efficient find all interval intersecting a point

Question

#include <iostream>
#include <boost/icl/split_interval_map.hpp>

using namespace std;
using namespace boost::icl;

int main()
{
    split_interval_map<double, int> intervals;

    intervals.add(make_pair(interval<double>::closed(0.,1.),0));
    intervals.add(make_pair(interval<double>::closed(1.,2.),1));
    intervals.add(make_pair(interval<double>::closed(3.,4.),2));
    intervals.add(make_pair(interval<double>::closed(2.,4.),3));
    intervals.add(make_pair(interval<double>::closed(1.5,3.5),4));

    std::vector<double> probes = { 0.23, 1., 1.33 , 1.57, 3.49, 3.51 };

    for(auto probe : probes)
    {
        std::cout << std::endl<< "probe " << probe << std::endl;
        auto lower = intervals.lower_bound(interval<double>::closed(probe, probe));
        auto upper = intervals.upper_bound(interval<double>::closed(probe, probe));
        while(lower != upper)
        {
            std::cout << lower->second << " ";
            ++lower;
        }
    }
}

1. What i get are the indices added up. But i'm looking for all the values (ints) of the interval containing 'probe'. (intersection?)
2. I could achieve this with std::set<int> as value, but in the documentation it is stated, that this has a huge impact on performance. Seems like split_interval_map contains that information but i don't know how to retrieve it it.
3. I need only a highly efficient lookup like in this example. I don't need the intersecting interval ranges anymore. Is boost icl too heavy for this?

Answer 1

1. What i get are the indices added up. But i'm looking for all the values (ints) of the interval containing 'probe'. (intersection?)

You get all the values (the co-domain values) combined using the combiner of your choosing. For an arithmetic type, that implies summation.

If your co-domain is an index, clearly summation is not meaningful combiner, and you should choose something else.

I could achieve this with std::set<int> as value, but in the documentation it is stated, that this has a huge impact on performance.

As always, correct goes before performance. If it's what you need, it's what you need.

Seems like split_interval_map contains that information but i don't know how to retrieve it it.

Not with the chosen co-domain: the combiner loses the original information if intervals overlap (and you use add, not set).

I need only a highly efficient lookup like in this example. I don't need the intersecting interval ranges anymore. Is boost icl too heavy for this?

You could use equal_range instead of lower_bound/upper_bound:

Live On Coliru

for (auto probe : { 0.23, 1., 1.33, 1.57, 3.49, 3.51 }) {
    std::cout << "\nprobe " << probe << ": ";

    for (auto& p : boost::make_iterator_range(m.equal_range(Ival::closed(probe, probe)))) {
        std::cout << p.second << " ";
    }
}

Prints

probe 0.23: 
probe 1: 1 
probe 1.33: 1 
probe 1.57: 4 
probe 3.49: 4 
probe 3.51: 3 

Observations:

m.add({Ival::closed(0., 1.), 0});
m.add({Ival::closed(1., 2.), 1});
m.add({Ival::closed(3., 4.), 2});

These intervals subtly overlap. [0, 1] and [1, 2] have [1,1] in common. Did you really mean left_open? ([0, 1) and [1, 2) have no overlap).

m.add({Ival::closed(2., 4.), 3});
m.add({Ival::closed(1.5, 3.5), 4});

If you were surprised by the fact that this combines the values already in the overlapping interval(s), did you mean to replace them?

m.set({Ival::closed(2., 4.), 3});
m.set({Ival::closed(1.5, 3.5), 4});

Alternatives, Ideas:

1. You could do the intersection with the set of probes at once:

   Live On Coliru

   Set probes;
   probes.insert(0.23);
   probes.insert(1.);
   probes.insert(1.33);
   probes.insert(1.57);
   probes.insert(3.49);
   probes.insert(3.51);
   std::cout << std::endl << "all: " << (m & probes) << "\n";
   

   Prints:

   all: {([1,1]->1)([1.33,1.33]->1)([1.57,1.57]->4)([3.49,3.49]->4)([3.51,3.51]->3)}
   

2. To (maybe?) optimize that a little:

   Live On Coliru

   using Map  = icl::split_interval_map<double, boost::container::flat_set<int> >;
   

3. If the sets are going to be small, consider specifying small_vector for that flat_set's sequence type:

   icl::split_interval_map<double,
       boost::container::flat_set<int, std::less<int>, 
           boost::container::small_vector<int, 4>
       > >;
   

   All else just still works: Live On Coliru

4. Completely OUT-OF-THE-BOX: are you modeling geometric regions? Like intervals on a timeline? Or just line-segments on an axis? In that case, consider boost::geometry::index::rtree<>