Boost logo

Glas :

Re: [glas] Skalar-Like concepts from GLAS and MTL

From: Peter Gottschling (pgottsch_at_[hidden])
Date: 2005-05-19 18:05:39

Hi Toon:

On May 19, 2005, at 3:54 PM, Toon Knapen wrote:

> Peter Gottschling wrote:
>> An important aspect of these concepts is that for instance
>> AdditiveGroup is a refinement of Group, as in the GLAS proposal, but
>> in an implementable way.
> I have to look into this further but I definitly support the use of
> functors.
> However I'm not convinced yet that they should be whereever you do.
> Now you define the AdditiveGroup to be a refinement of
> {T,glas::def::groupAddOp<T>}. Additionally you propose in section 5.1
> to derive the functors from the operators. So would'nt it be more
> straigthforward to require an operator+ (global or as a member) in the
> concept itself.
So, let me try to convince you. The weak point is probably not the
concept definition but its description.

Let's look at AdditiveGroup from another perspective. What a type T
needs to model it?
- The expression a+b, a+=b, -a, a-b, a-=b must be defined
- The addition and subtraction must be associative
- a + -a must be T(0) (* I already mentioned in the paper that this
notion of zero might be too casual *)

Notice that T can model AdditiveGroup without the existence of a
functor. Furthermore, every type models AdditiveGroup in my definition
_iff_ it models AdditiveGroup in the GLAS definition.

The type requirements are not more complicated than in the other
proposal, only the concept definitions are. Why?

The answer is that this style of definition provides consistency
between the additive concepts and the pure algebraic concepts, which is
absolutely needed to consider the additive concepts as refinements of
pure algebraic concepts. If there is another way to guarantee this
consistency, we should discuss it. The definition in the GLAS concept
was for my personal taste a little bit to general to lead the
implementing in sufficient detail. The technique (or trick if you want)
with the default functor nails down the consistency.

Concerning algorithms, template functions for additive or
multiplicative concepts can be written completely in terms of operators
(without any trace of a functor). Template functions for pure algebraic
concepts need of course functors. However, due to the consistency, any
type that models for instance AdditiveGroup or MultiplicativeGroup can
call any function requiring Group by passing the default functor as
extra parameter, like in section 5.5 where no functor is implemented in
the complete example.

>> In addition, pure algebraic structures are not only defined
>> informally but also as concepts for C++ template code and several
>> examples are given how to use them. As a result of the concept
>> refinements, each type modeling a multiplicative or additive concept
>> can call functions for the corresponding pure algebraic concepts
>> using default functors.
>> The concepts so far cover the area of scalar-like concepts (and even
>> there are still some open details). I added some sources to play
>> around with. Any comment is welcome.
> As for the 'pure algebraic concepts', your concept definitions are in
> line (but more detailed) of the current glas proposal. So I propose to
> merge these in the current proposal.
I am happy to read this. :-)

> As for section 5.1 I'm wondering if it would'nt be interesting to only
> associate functors with properties that introduce a new 'keyword'. For
> instance, looking at the properties of Group, closure and
> associativity are implicitly used, whereas for getting the identity or
> the inverse of an element, some explicit call (to a function) must be
> performed.
Again, this a result of the description. Discussing issues of
associativity and commutativity in section 6, I dropped some details in
5.1 to explain my ideas step by step. In 6.1, I added some markers to
handle these attributes, and then all functors are really different.
The code from section 5.1 is in default_functors_wo_markers.hpp and the
final version, which is only partly printed in section 6.1, is in

Peter Gottschling
Research Associate
Open Systems Laboratory
Indiana University
215 Lindley Hall
Bloomington, IN 47405
Tel.: +1 812 855-8898 Fax: +1 812 856 0853