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

From: Peter Gottschling (pgottsch_at_[hidden])
Date: 2005-05-20 13:40:12

I now retract everything and argue the converse.  The additive concepts 
can be written in terms of operators and still provide consistency with 
the pure algebraic concepts.

WLOG, let's take out a+= b, a-=b, and a-b, which are only syntactical 
sugar, then we have the following implication:
{T,groupAddOp<T>} models Group    -->   a+b, -a are defined, T(0) is 
identity, and a + -a = T(0), a+b is ass.

On May 19, 2005, at 6:05 PM, Peter Gottschling wrote:

> 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
>
> _______________________________________________
> glas mailing list
> glas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/glas
>
------------
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