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

**From:** Matthias Troyer (*troyer_at_[hidden]*)

**Date:** 2005-03-25 20:38:00

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

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.

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.

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.

Best,

Matthias

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