Re: [boost] [Review] ITL review starts today, February 18th

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-28 19:31:05

----- Original Message ----- 
From: "Joachim Faulhaber" <afojgo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, March 01, 2010 12:23 AM
Subject: Re: [boost] [Review] ITL review starts today, February 18th

> 
> Hi Barend,
> 
> thank you again for all the effort and diligence that you invested to
> investigate my library :)
> 
> I am going to address the issues you raised piecemeal in a sequence of
> importance that I consider for them. Generalized addition, subtraction and
> intersection operators are at the heart of the library. So I'll begin here:
> 
> 5) OPERATORS and FUNCTIONS
> 
>> During the review period I had a discussion on the list with Joachim about
>> the operators and the naming of functions. However, I thought that the +=
>> and |= were both doing a pure union, but it appears that they are doing a
>> union PLUS a (sometimes mathematic) addition.
> 
> 
> this is correct.
> 
> As I have outlined in the documentation, all Sets and Maps of the ITL are
> Addable and Subtractable. Addability is more fundamental than
> Subtractability. Addability in the sense I have in mind could also be called
> Combinability: Some kind of a primary possibility to combine values of a
> type T:
> 
> string, sequence : concatenation
> numbers : addition
> sets : union
> maps : ? ... Since a map is a set of pairs we could use set union. But this
> is NOT done in the ITL. The ITL defines a generalized addition, based on a
> union operation, that propagates operator + to combine associated values, if
> the inserted intervals overlap (or inserted elements collide).
> 
> By default we propagate operator + to combine associated values. This yields
> to
> concatenation, if lists, strings, etc. are associated
> addition, if numbers are associated
> union, if sets are associated
> generalized union, if maps are associated.
> This is [reason 1], why union on sets and generalized union on maps must be
> expressed to operator +, +=

>From the examples, the single type that supports the operators + and += are numbers and strings. Maybe it is not a good idea to use the operators for the library, but just clear names. 

 
> See also:
> http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/concepts/addability__subtractability_and_aggregate_on_overlap.html
> 
> So again, this design is based on the assumption, that, for a combinable
> type T, we can identify a primary operation for the combination of it's
> values and for this primary operations we expect operator + . This is
> crucial for the combination of maps in the ITL. Maps propagate this primary
> combine function. And as default we always use operator + . Since associated
> type can be sets, interval_sets and, yes, maps and interval_maps : We must
> assign operator + to the primary way of combining sets and maps in the ITL.
> Because, by introducing a generalized addition on maps, we start to
> propagate the combination operator. The best choice for this? Clearly the
> archetypal operator that is there for the combination of *something*:
> operator + .

Have you think about adding the Combiner Trait template parameter not to the container class, but to the container operation (add, substract, ...)? Of course this eliminates the use of operators + +=. but IMO is clearer, you add a new element to a map if not ovelap, otherwise the operator use the combiner on the overlaping interval.

for example if I have {[2,4)->5, [6,7)->10, [12, 15)->0}

adding [1, 10)->1) could result in {[1, 10)->1, [12, 15)->0)} if the combiner gives the new value for the overlaping intervals.

Best,
Vicente
 
Best,
Vicente