# Glas :

## 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
>> 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.: +1 812 855-8898 Fax: +1 812 856 0853

>
> _______________________________________________
> glas mailing list
> glas_at_[hidden]

>
------------
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
http://www.osl.iu.edu/~pgottsch