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-27 08:17:34

Hi Joachim,

>   
>> 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).
>>
>>
>>     
>
> (1) They are not (yet) producible in c++. We have to get by on a small set
> of them. So its unwise to waste them.
>   
Yep

> (2) operators are like semantical archetypes. Pretty early in school we make
> contact with =, <, +, - . They carry semantical invariants not only for
> mathematicians but for almost every educated human being. This is like a
> treasure that can be harnessed for those parts of generic libraries that we
> want to be maximally intuitive to use.
>   
I understand but only if it is really intuitive for everyone. I've seen 
that you refer to segmentational fineness, coupled to operator>, which 
is for me not so intuitive ("x > y   // means that x is_finer_than y"). 
I would state that a function with a describing term is often more easy 
to use and to interpret.

> (3) While with += and |= I feel kind of coerced to assign the same
> semantics:
>    + is the primary operator of combining object of some type, which is
> union (for sets)
>    |  is equivalently intuitive from the boolean view of set union a | b = {
> x : x in a || x in b}
>   
I doubt that += is so intuitive in this case. Combined with a scalar, an 
interval [2,5) += 3 might intuitively go to [5,8), e.g. delayed by 3 
minutes.. I like the symmetry of || and && for or/and and |= and &= for 
union and intersection, which are the or and and in set theory. 
Therefore, I would reserve the += for something else, because they are 
sparse, as you stated  ;-). Or just don't use it.

On the other hand, the difference is -=, so subtracting a set, and a 
union is +=, so adding a set, yes it is intuitive and symmetric...
We need the operators U and U/upsidedown here to make it mathematical... ;-)

> (4) With *= and &= this is different. * is in my view not an "archetype" for
> intersection.
>   
I do agree with that. Besides that, the *= might stand for the Cartesian 
product as well.

> (5) Yet, the most important reason is that I'd like to save * for scaling:
> 2 * {1,2} = {2,4} because this *is* IMO an archetypal meaning  for *
> (6) In the more freaky parts of my semancial studies on interval_maps I
> found that specific instantiations e.g.:
> interval_map<int,double,total_absorber> are models of a concept 'indefinite
> vector' of a vector space, if a scalar multiplication was added. To be able
> to add this basic operation later I wanted to save * and *= .
>   
Yes, 2* is inuitively convenient for scaling, but is scaling of 
intervals an often occuring need?. In the 2/3 D case we have 
transformations which scale,translate and rotate, here you probably have 
scale and translate, and I think I would not attach an operator on it, 
or make it consequent with translation...

There is another function as well, not being discussed yet, what we in 
GIS call the "buffer". So {1,2}  buffered by 0.1 would be {0.9,2.1}. Is 
that supported by ITL and do you think it needs an operator, and which? 
It is different than scaling because an interval set {1,2},{3,4} would 
be {0.9,2.1},{2.9,4.1}. For intervals useful if you need 5 minutes extra 
in all schedules on both sides.

>
> I am always struggling with this:
>    is_whatever(x) : This is my preference for boolean functions (except
> natural cases like intersects, contains), because
>    whatever(x)  is often a good choice for a non boolean function. On the
> other hand the whatever(x) version is
>   stl-style and also of course generally shorter.
>   
So why actually is "contains" a natural case and "disjoint" is not? You 
are right that disjoint == !intersects and !disjoint is a sort of double 
negation. But that is the same for !is_disjoint...

>  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?
>>
>> The more fundamental concepts are, and sets / maps are *very* fundamental,
>>     
> the more important is the quest for a really good, intuitive and systematic
> naming. I am in favor of that and I am willing to adapt.
>   
OK. So we have fundamental concepts for at least operators, and for 
boolean operators which overlap these libraries...

Regards, Barend