|
|
Glas :RE: [glas] Vector Spaces vs. "Objects called vectors" |
From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-02-03 18:28:46
On Thu, 3 Feb 2005, Edwards, Harold C wrote:
[...]
> Question regarding the definition of a "vector" in this discussion:
> 1) A value in a given finite-dimensional Vector Space (math)
> 2) A finite collection of elements (with contiguous storage) (cs).
The first.
>
> If the math-definition then is the software-design concept for such a
> vector to allow it to be reassigned to different vector spaces, or
> locked into the vector space for which it is created? E.g., changing
> the size of a vector, or the FEM example, reassigns the vector's
> underlying vector space. It seems the policy is whether or not an
> "object called a vector" can be locked into a vector space or reassigned
> among vector spaces.
Clearly, in a lot of cases it doesn't make sense to resize the vector.
eg, "x += y", x and y should be the same size. The only case where it
would be sensible to consider resizing is for ordinary assignment. Here,
I don't think it is even sensible to fix a policy, if only for
interoperability reasons (how would you prevent a resize for std::vector?
How would you allow resize for a fixed-size array?).
If you can't resize containers through assignment, then some
tasks, such as initializing a block-partitioned matrix (ie. a
matrix<matrix<double> > or somesuch) becomes more difficult than it ought
to be. And there has yet to be a credible reason why resize shouldn't be
allowed.
>
> It may be useful to expand the software design notion of a vector space
> beyond the element type and dimension to allow the above FEM example.
> This opens the door to other considerations, such as including parallel
> partitioning or other substructuring information in the software design
> of a vector space.
The FEM example was a red-herring because the underlying vector spaces are
the same, the additional type information that one might want to give them
has nothing to do with vectors per se. OTOH, partitioning and structure
certainly are relevant and need to be included at some level in the
concepts that the vector conform to. I think this is already understood
by the MTL plan (http://boost-consulting.com/projects/mtl/html/plan.html),
and in a somewhat different way by the glas storage concepts
(http://www.femtown.org/glas/doc/). Of course, both schemes can/will be
extended to support other structures (distributed, etc).
Cheers,
Ian McCulloch