Boost logo

Glas :

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

From: Peter Gottschling (pgottsch_at_[hidden])
Date: 2005-05-23 18:03:52

Hello Karl and Toon:

On May 23, 2005, at 4:20 PM, Toon Knapen wrote:

> 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 just realized that there are different interpretations of the term
functor. Stroustrup defines it in his book in section 18.4 as an object
of a class with an application operator. I prefer the definition in the
STL, which includes free functions as pointers
( So, we should make it
clear that we use functor in its more general meaning.
>> * 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.
 From my perspective, there is no essential difference between the
mathematical definition of group and the concept, it is only
syntactical not semantical.
> 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?
> _______________________________________________
> 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