## Glas :## Re: [glas] vector space, banach space and hilbert space concepts |

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

**Date:** 2005-03-26 02:47:11

**Next message:**Karl Meerbergen: "Re: [glas] vector space, banach space and hilbert space concepts"**Previous message:**Matthias Troyer: "Re: [glas] vector space, banach space and hilbert space concepts"**In reply to:**Matthias Troyer: "Re: [glas] vector space, banach space and hilbert space concepts"**Next in thread:**Karl Meerbergen: "Re: [glas] concepts, algorithms etc"

On Saturday 26 March 2005 02:38, Matthias Troyer wrote:

> Hi Karl,

>

> I glanced over a few of the concepts and have some remarks. In my

> opinion these concepts are too narrow, i.e. many types which would

> model the concept in its mathematical sense are excluded by your

> definitions. I give some examples below:

>

> In the Banach space concept you require a member function v.norm().

> This is very restrictive since there exist cases where I cannot add a

> norm function to a vector type, e.g. if the vector type is provided by

> a library not written by me. A free norm(v) function would be greatly

> preferred. There are other cases similar cases you also require member

> functions, and free functions would be preferred.

A free function is fine. It really does not matter much, I think. You should

be able to make a free function a member function by wrapping it in a class

(model of BanachSpace).

The reason why I made norm() a member function is that a Banach space has a

unique norm function.

There are an infinite number of norm functions for Vector, and these are best

free functions. E.g. norm_2(v), norm_1(v), norm_inf(v). I think a free

function norm(v) for Vector and Matrix is not a good idea, because which norm

are you going to use?

A similar comment holds for HilbertSpace. The inner_product is proposed as a

free function, but it could also be v.inner_prod(w).

Anyway, I am not sure BanachSpace is a concept we should keep. If there is no

need for it, we can drop it.

>

> Secondly, you require in the vector concepts that a vector "contains n

> entries of type value_type, numbered from 0 to n-1", and that there is

> a constructor "X(n)". I also find this to be far too restrictive. For

> me, a vector is just an element of a vector space. What you describe is

> a possible (and common) representation of a vector by its coordinates

> in a certain basis set, but again this is too restrictive. For example,

> if I were to write a linear solver, I would want to pass a linear

> operator A, and a vector b, and get back the solution vector x of the

> equation A*x=b. If you were to code such a solver, and require that b

> follows your vector concept, you impose far too many constraints. In

> some of our applications the vector is, for example, represented by a

> 3-dimensional array and has no constructor X(n). I would thus prefer to

> just define a vector as an element of a vector space, and not confuse

> it with a one-dimensional array.

The way you this describe this, you do not need a Vector concept in your

iterativesolver, but VectorSpace of HilbertSpace because this is what your

iterative method probably needs.

Maybe there is some confusion in the concepts: Vector and Matrix are

specializations of VectorSpace (or restrictions if you like). Perhaps, the

VectorSpace concept should be renamed into VectorSpaceElement.

Mike Heroux gave some interesting suggestions to enrich the VectorSpace

concept with size (or dimension) related functions. A VectorSpace(Element)

can then be constructed using this size information.

>

> Finally I do not fully understand your comment:

> > The Vector concept allows for a scalar multiplication with a scalar of

> > a different value_type as the Vector, the Matrix concept does not. An

> > important advantage I see is that the Vector allows scalar

> > multiplication for something like vector< vector<T > >.

>

> If T here is the scalar type of your vector space, and vector<vector<T>

>

> > the vector type of some vector space, then I do not see any problems

>

> restricting the multiplication. I believe again that there is a

> confusion here between the concept "vector" as element of a vector

> space and the "vector" class, implementing a one-dimensional array.

> Indeed, I suppose that the "value_type" of vector<vector<T> > is

> vector<T> and not the scalar type of your vector space, which would be

> T. Cleaning up the vector concept, and clearly distinguishing between

> the "vector" concept and the "one-dimensional array" as implemented

> e.g. by std::vector would solve this issue more elegantly.

So, perhaps it is best to use the name VectorSpaceElement to clearly make this

distinction? Would this take away the confusion?

The same holds for BanachSpace, HilbertSpace, EuclideanSpace, etc.

Perhaps a better example would be a space of vector<polyonomial> where you

allow the multiplication with a double. The value_type is polynomial, the

scalar_type double.

Thanks for your comments.

Karl

**Next message:**Karl Meerbergen: "Re: [glas] vector space, banach space and hilbert space concepts"**Previous message:**Matthias Troyer: "Re: [glas] vector space, banach space and hilbert space concepts"**In reply to:**Matthias Troyer: "Re: [glas] vector space, banach space and hilbert space concepts"**Next in thread:**Karl Meerbergen: "Re: [glas] concepts, algorithms etc"