## Glas :## RE: [glas] Vector Spaces vs. "Objects called vectors" |

**From:** Ian McCulloch (*ianmcc_at_[hidden]*)

**Date:** 2005-02-03 18:28:46

**Next message:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Previous message:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**In reply to:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Next in thread:**Kevin Wheatley: "Re: [glas] Vector Spaces vs. "Objects called vectors""**Reply:**Kevin Wheatley: "Re: [glas] Vector Spaces vs. "Objects called vectors""

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

**Next message:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Previous message:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**In reply to:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Next in thread:**Kevin Wheatley: "Re: [glas] Vector Spaces vs. "Objects called vectors""**Reply:**Kevin Wheatley: "Re: [glas] Vector Spaces vs. "Objects called vectors""