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

**From:** Peter Gottschling (*pgottsch_at_[hidden]*)

**Date:** 2005-05-19 18:05:39

**Next message:**Peter Gottschling: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Previous message:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**In reply to:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Next in thread:**Peter Gottschling: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Reply:**Peter Gottschling: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Reply:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Reply:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"

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

http://www.osl.iu.edu/~pgottsch

**Next message:**Peter Gottschling: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Previous message:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**In reply to:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Next in thread:**Peter Gottschling: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Reply:**Peter Gottschling: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Reply:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Reply:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"