|
|
Glas :Re: [glas] norms and inner products for vectors of matrices |
From: Russell Smiley (smiley_at_[hidden])
Date: 2006-01-17 09:11:23
While I can see that it's true that vector<vector<double> > is ambiguous
in terms of how operators might be applied to it (ie. Is this a
representation of a matrix, etc) , I don't quite understand why we have
to maintain that ambiguity in a numerical library.
What is wrong with having a concrete type 'matrix' (along with others)
such that you can still use vector<vector<double> > if necessary, but
resolve the ambiguity when needed?
For example:
vector<vector<double> > v;
// do some stuff with v...
Y = v*v;
// perhaps v*v is scalar multiple of elements of v;
// now assign v to the matrix so we can do some operations on it,
// making it clear that this is a diagonal matrix, somehow.
matrix<double> m(v, matrix::diagonal);
// etc, or
matrix<double, matrix::diagonal> m(v);
Z = m*m;
// now m*m (implicitly v*v) is matrix multiply of some form.
I assume there is some penalty for the assignment (perhaps not a
significant one if it's a reference copy) but at least the ambiguity is
resolved and syntactically it's fairly transparent/simple.
Russell.
> -----Original Message-----
> From: glas-bounces_at_[hidden]
> [mailto:glas-bounces_at_[hidden]] On Behalf Of Andrew Lumsdaine
> Sent: Tuesday, January 17, 2006 8:51 AM
> To: Generic Linear Algorithm Software
> Subject: Re: [glas] norms and inner products for vectors of matrices
>
>
> I think the answer is: "it depends."
>
> In a generic library, the operator * is defined between two concepts
> for which multiplication makes sense, i.e., a scalar times a scalar,
> a scalar times a member of a vector space, a linear operator times a
> member of a vector space.
>
> So, if you have some particular types, the meaning of the operator *
> between those types depends on the manner in which those types model
> the concepts for which * is defined.
>
> For instance, a vector<vector<double>> could be a row matrix, a
> column matrix, a diagonal matrix, a banded matrix, etc. Each of
> these different interpretations of that type (different ways
> the type
> can model the concept) will have different interpretations of the
> multiply operator.
>
> I think it is very important to keep the mathematical concepts and
> the concrete implementations distinct from each other.
>