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

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2010-02-27 10:56:45

2010/2/27 Barend Gehrels <barend_at_[hidden]>

> Hi Joachim,
>
>
>  (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.
>
> The example is a little specific. The operator > is induced by the fact
that segmentational_fineness<T>::value yields an integer constant, which is
larger if the type T is finer.

Looking at the stl I think operator < is a good example for a very pervasive
operator with a consistent interpretation across a lot of class and function
templates. It is also generally expected as default for compare functor
types. I would say that operator < in the stl is the classical example for a
consistent and pervasive usage of an operator.

 (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.
>
> ... hmm ... I have thought about that as well. [2,5) += 3 starts to
introduce interval arithmetics. Although this could be pretty handy I
decided to leave interval arithmetics out. The reason is, that the
domain_type of intervals and interval containers does not need to be a
number. It only requires a strict weak ordering. So arithmetic operations
would work for a subset of all possible domain_types only.

For numeric domain_types it is obviously interesting to be able to perform
arithmetic operations and to reserve += for that. To keep things simple I
ruled that out for the time being. But yes, this is an argument to think
about *saving* operator += . But there are more problems. If we defined +=
for arithmetic addition (e.g. on interval_sets), we would want to use -= for
subtraction, which is already occupied for set difference :(

> 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.

Right, also a good candidate.

>
>
>  (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?.

Yes, we had use cases, where we had intervals from of different time
granularity. So we had to scale them to a common time scale. For the boost
submission I took that function out of the ITL. But it has its
applications.

> 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.
>
> Seems not terribly essential to me but may be useful to add.

>
>> 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?
>
> (1) My glass contains beer.
(2) Your glass disjoint from mine.
=)

>  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...
>
> In a way all of boost is kind of an effort to converge on common designs,
concepts and notations. I like that =)

Best,
Joachim