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

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Barend Gehrels (barend_at_[hidden])
Date: 2010-02-26 17:27:27

Hi Joachim,

This is not yet the review.

I'm about halfway and I'm enthousiastic. I've done two small projects 
inspired on my needs and all I tried is working good, it definitely is a 
useful library.

Questions /remarks though.

1) The set union is modelled as += (doc: "So interval_sets define an 
operator += that is naturally implemented as set union and an operator 
-= that is consequently implemented as set difference"), set 
intersection as &= (according to the doc definition and man_power sample).

However, a union is more or less like an OR operation, an intersection 
like and AND operation, so I would have expected that union would be |=. 
According to the manual, in another place, that is also supported.

Boost.Polygon(BP)/GTL also supports both, for union. Is it intentional 
that two operators are implemented for the same operation in these two 
libraries? And if so, why is that not done for the intersection (having 
synonym *= in BP).

Boost.dynamic_bitset also implement all of these:
dynamic_bitset& operator&=(const dynamic_bitset& b); Bitwise-AND   ...
dynamic_bitset& operator|=(const dynamic_bitset& b); Bitwise-OR's...
dynamic_bitset& operator^=(const dynamic_bitset& b); Bitwise-XOR's...
dynamic_bitset& operator-=(const dynamic_bitset& b);  Computes the set 
difference of this bitset...
  

Boost.Geometry does not (yet) implement operators so we look in a way to 
conform, if possible, and would like to avoid to introduce synonyms. So 
I would advocate, for (at least) the four libraries 
Boost.dynamic_bitset, Boost.Polygon, Boost.Geometry and ITL, the usage 
of operators conform dynamic bitset, so the following:
&= for intersection
|= for union
^= for symmetric difference (as is done in both ITL and BP)
-= for difference (as is done in both ITL and BP)

2) Same scope, the "boolean" functions "is_disjoint", "contained_in", we 
in Boost.Geometry have named them (according to ISO/OGC) as "disjoint" 
and "within". The following functions match: "intersects", "contains" 
and "touches". And, besides that, ISO/OGC also describe "equals", 
"overlaps" (where overlaps is roughly intersects, but not completely 
within, and not touches).

So actually we're nearly there, there are just some small differences in 
names/synonyms.

Do you find it a good idea to have / create a common picture of 
operators and functions and if yes, is it still possible to adapt?

Regards, Barend