## Glas :## Re: [glas] concepts, algorithms etc |

**From:** Karl Meerbergen (*Karl.Meerbergen_at_[hidden]*)

**Date:** 2005-03-12 06:31:47

**Next message:**Karl Meerbergen: "Re: [glas] concepts, algorithms etc"**Previous message:**plagne.laurent_at_[hidden]: "[glas] multilevel block-matrices"**In reply to:**Andrew Lumsdaine: "Re: [glas] concepts, algorithms etc"**Next in thread:**Karl Meerbergen: "Re: [glas] concepts, algorithms etc"**Reply:**Karl Meerbergen: "Re: [glas] concepts, algorithms etc"

Andrew,

This is all clear to me. Perhaps I was too carried away by the fact that GLAS

stands for generic linear algebra software and that the goal is to develop

linear algebra software.

If there really is a need for a VectorSpace concept, which I can understand in

some situations, e.g. when working with polynomial spaces, ok, fine.

The VectorSpace concept allows for the operations

Scalar * VectorSpace

and VectorSpace + VectorSpace

So, for a vector/matrix library (which GLAS is supposed to become) this allows

for:

Scalar * Vector

Scalar * Matrix

Scalar * SparseMatrix

Scalar * ToeplitzMatrix,

etc.

(Recall that matrices are also members of a vector space)

If the VectorSpace is a Vector or a Matrix, and the value_type of Vector, and

Matrix and Scalar are the same, then we are in the traditional numerical

linear algebra. This is the minimum requirement I want to achieve and I think

many of us. And this is well described in the book by Golub and Van Loan.

The only situation I see where a VectorSpace concept is useful, is when the

value_type of Scalar and Vector (and Matrix) are different. In the other

cases, assuming the value_type is in a field, algebraic vectors and matrices

are members of vector spaces. Tell me if I am wrong.

Even for iterative methods, eigenvalue solvers etc (which happens to be my

expertise), it is not sufficient to define the concepts VectorSpace and

HilbertSpace.

Perhaps we should make a list of very specific examples we would like to

support with GLAS and from this make the required concepts. Otherwise we

continue arguing that we need or need not a VectorSpace concept.

Karl

On Friday 11 March 2005 16:56, Andrew Lumsdaine wrote:

> This question raises an important issue regarding generic library

> development. Designing concepts (and designing for genericity) is not

> the same as designing for base classes. That is, a concept hierarchy

> should reflect the absolute *minimum* amount of functionality necessary

> for the algorithms of interest to operate (and to operate efficiently).

> This allows each algorithm to work with the maximum number of actual

> types.

>

> The idea is not to create a concept as a "grand unified type

> specification" that includes all possible functionality and then write

> all algorithms to take the same types. If an algorithm is specified

> with unnecessary requirements, it will limit its range of

> applicability. That is, one wants a set of algorithms that look likes:

>

> template <typename Monoid>

> void foo (Monoid& z, const Monoid& y, const Monoid& x);

>

> template <typename Field>

> void bar (Field& z, const Field& y, const Field& x);

>

> template <typename VectorSpace>

> void baz(VectorSpace& z, const VectorSpace& y, const VectorSpace& x);

>

> template <typename HilbertSpace>

> void zip(HilbertSpace& z, const HilbertSpace& y, const HilbertSpace& x);

>

> Specifying all of these algorithms in terms of the type with the most

> requirements (e.g,. HilbertSpace) would mean that foo() could not be

> correctly used with types that model Monoid but not HilbertSpace.

>

> Regards,

> Andrew Lumsdaine

>

> On Mar 11, 2005, at 4:23 PM, David Abrahams wrote:

> >> My question is: why do we need a VectorSpace concept?

> >

> > Are there algorithms/functions you'll be implementing that actually

> > require only Vector Space, but not Linear Algebra? If so, you will

> > overconstrain their arguments in the specification by using Linear

> > Algebra in the requirements.

>

> _______________________________________________

> 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: +32 10 45 12 26 Company Fax: +32 10 45 46 26 Mobile Phone: +32 474 26 66 59 Home Phone: +32 2 306 38 10 mailto:Karl.Meerbergen_at_[hidden] http://www.fft.be ==============================================

**Next message:**Karl Meerbergen: "Re: [glas] concepts, algorithms etc"**Previous message:**plagne.laurent_at_[hidden]: "[glas] multilevel block-matrices"**In reply to:**Andrew Lumsdaine: "Re: [glas] concepts, algorithms etc"**Next in thread:**Karl Meerbergen: "Re: [glas] concepts, algorithms etc"**Reply:**Karl Meerbergen: "Re: [glas] concepts, algorithms etc"