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

**From:** Edwards, Harold C (*hcedwar_at_[hidden]*)

**Date:** 2005-02-03 17:29:57

**Next message:**Ian McCulloch: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Previous message:**Patrick Kowalzick: "Re: [glas] MTL3 design ? [was MTL project site is up]"**Next in thread:**Ian McCulloch: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Reply:**Ian McCulloch: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Maybe reply:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Maybe reply:**Williams, Alan B: "RE: [glas] Vector Spaces vs. "Objects called vectors""

> > >> > I think it will not be uncommon to wish to forbid even

assignment

> > >> > between vectors of equal size, for example if one represents

> > >> > cell-based and the other one vertex-based quantities (speaking

> > >> > FEM). So one could introduce mechanisms to forbid assignment at

> > >> > compile time (i.e. making those vectors different types).

> > >> Or const?

> > >>

> > >

> > > No, because I still want to be able to assign vectors of the same

> > > (mathematical!) 'type'. Assignment is really just a special case:

> > > Think of operations like addition where we also will have to

> > > carefully decide which combinations are allowed and which are not.

> > > "Same c++ type" is not the only useful criterion here.

> >

> > It's usually the best one. Vectors et al. are "scalar" quantities

> > (like pi). You can always add type information later per

> > http://article.gmane.org/gmane.comp.lib.boost.devel/117232

>

> Heh, we enter the world of overlapping/conflicting

> definitions. But I

> agree completely. A vector is a simple abstraction for a

> function from

> a (finite, contiguous) set of integers to some type T.

> Anything beyond

> that belongs elsewhere.

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

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.

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.

--Carter Edwards

**Next message:**Ian McCulloch: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Previous message:**Patrick Kowalzick: "Re: [glas] MTL3 design ? [was MTL project site is up]"**Next in thread:**Ian McCulloch: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Reply:**Ian McCulloch: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Maybe reply:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Maybe reply:**Williams, Alan B: "RE: [glas] Vector Spaces vs. "Objects called vectors""