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

From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-05-23 02:50:45

Hello Peter,

I have the following remarks and suggestions:

* the AdditiveGroup (and perhaps MultiplicativeGroup) are the most 
important ones because these are needed in linear algebra operations.

* Perhaps it would be better not to talk about functors in the concepts. 
What we need in a Magma is some function op(x,y). This is a free 
function that can be implemented using a functor, but does not have to.

* I would call the corresponding Group concept, OpGroup, because it has 
a function op. The mathematical concept group is not exactly a C++ 
concept and there are various ways to define those. AdditiveGroup is not 
an OpGroup (because it does not have a member op), but an addaptor can 
be created that maps it into an OpGroup.

* I am thinking one step ahead now: our goal is not develop software for 
scalar operations but for vector and matrix classes. From an OpGroup for 
scalars, an OpGroup for a vector can be created. The same free function 
op() can be used for op()'s on vectors. With the functors this is much 
more difficult.

* For an  OpRing, we need op1() and op2() ?

The major question is:
do we need very generic operations? Is there a need for that? I am not 
convinced this is needed. I see situations where it might be useful, but 
do we need to support these in GLAS? My feeling is that this is 
something that can easily be added later, when it appears to be needed. 
Currently I would concentrate on + and * only.

What do you think?

Karl

Peter Gottschling wrote:

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

-- 
==============================================
Look at our unique training program and
Register on-line at http://www.fft.be/?id=35
----------------------------------------------
Karl Meerbergen
Free Field Technologies
16 place de l'Université
B-1348 Louvain-la-Neuve - BELGIUM
Company Phone:  [phone]
Company Fax:    [phone]
Mobile Phone:   [phone]
Home Phone:     [phone]
mailto:Karl.Meerbergen_at_[hidden]
http://www.fft.be
==============================================