Boost logo

Boost Users :

Subject: Re: [Boost-users] ICL library usage for interval map
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-06-05 08:37:04


Hi Dave,

thank you for using Boost.ICL. From your example, I am not completely
sure I understand what you are trying to accomplish. In any case you
have to distinguish between

interval_sets and
interval_maps

2011/6/3 Dave Schwartz <decebel_at_[hidden]>:
> Hi Users,
>
> I am trying to use the new ICL (interval container library) for a
> project that requires some interval based calculations.
> I have a question on using the joining interval_map.
>
> For example, below I have a conceptual 30 minute window divided into
> three 10 minute intervals. I want to do some aggregates in my 10
> minute windows.
> { [0,10], (10, 20], (20, 30) }

As you are not using associated values I assume you should better use
an interval_set.

> Now say, I have 2 clients shopping in the first interval (0, 10) and
> their shopping time window interval is [2, 5] and [4, 9] minutes
> respectively.
> When I add the 2 interval, value pairs to my interval_map, I see that
> the interval map gets splited from [0, 10] to { [0,2], [2, 4], [5,9],
> [9,10] }.
> How do I make sure the interval still remains from [0, 10].

By using an interval_set, which is joining, and does not have associated values.

> My question is how do I make sure my original interval of 10 minutes
> is preserved. The samples mentioned do mention about joining
> interval_map but I cannot seem to figure out an example for my
> requirement.

Use interval_set, if you don't need to store and aggregate associated values.

In contrast to interval_sets, interval_maps have to split intervals on
aggregation. See e.g.
http://www.joachim-faulhaber.de/boost_icl/doc/libs/icl/doc/html/boost_icl/examples/overlap_counter.html

HTH
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net