Glas List: 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 
default_functors.hpp.

Best,
Peter
------------
Peter Gottschling
Research Associate
Open Systems Laboratory
Indiana University
215 Lindley Hall
Bloomington, IN 47405
Tel.: [phone]   Fax: [phone]
http://www.osl.iu.edu/~pgottsch