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