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

**From:** Toon Knapen (*toon.knapen_at_[hidden]*)

**Date:** 2005-05-23 16:20:30

**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:**Karl Meerbergen: "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"

Karl Meerbergen wrote:

> Hello Peter,

>

> * 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.

But what 'op' actually is must be kept abstract. The actual name does

not matter. The 'op' is just of a type 'Op'. And Op is the type of a

function that takes 2 arguments (like in 'T (*Op)(const T&, const T&)')

>

> * 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.

As I mention above. 'op' is just a function of type 'Op'. For the

additive-group this 'op' is just called 'plus' which is a function that

relies on the operator+.

>

> * 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() ?

This kind of 'making abstraction of what actually the two operators of

the Ring do' only serves in algorithms where we actually want to make

abstraction of the operation being performed. For instance an algorithm

like the multiplyAndSquare in section 5.3 of Peter's paper (although the

'multiply' in the name of the function is maybe not a good choise

because it's up to the operator being passed what the operator will

actually do). In the case we want the algorithm makes abstraction of

actually what the operator does, we can indeed pas a function/functor.

I think it would be instructive to ask us the very practical questions:

how do we allow a matrix-matrix multiply and an elemtwise-matrix

multiply without clearly penalising one over the other. This is a

practical problem where we want to map both operations to the operator*

so how do we practically solve that. Or same with the norm-function.

Which norm (1-norm,2-norm,...) do we map to the function called norm?

**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:**Karl Meerbergen: "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"