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