## Glas :## RE: [glas] summary: auto-resizing vectors in assignment |

**From:** Williams, Alan B (*william_at_[hidden]*)

**Date:** 2005-02-04 11:58:08

**Next message:**Andrew Lumsdaine: "Re: [glas] summary: auto-resizing vectors in assignment"**Previous message:**Edwards, Harold C: "RE: [glas] summary: auto-resizing vectors in assignment"**Maybe in reply to:**Toon Knapen: "[glas] summary: auto-resizing vectors in assignment"**Next in thread:**Andrew Lumsdaine: "Re: [glas] summary: auto-resizing vectors in assignment"**Reply:**Andrew Lumsdaine: "Re: [glas] summary: auto-resizing vectors in assignment"

As Carter points out, there is already a good understanding of the

mathematical concept of vector-spaces, vector-subspaces, vectors which

are members of them, etc. Obviously opinions will differ on how best to

represent mathematical concepts using computer science. One example

which may bear consideration is the TSFCore effort (TSF stands for

Trilinos Solver Framework) which contains classes that represent

VectorSpaces, Vectors, etc. If interested, visit this URL:

http://software.sandia.gov/Trilinos/packages/tsfcore/doxygen/development

/inline/index.html

The discussions on GLAS so far remind me of an effort we were involved

in a few years ago called ESI (equation solver interfaces), which

attempted to define various entities that are of use in linear algebra,

such as vectors, linear-operators, solvers, preconditioners. A couple of

years were spent vigorously arguing over how each entity should behave,

until finally most people lost interest and the effort died. I think the

lesson to be learned from that is to have a clearly defined scope and

attainable goals from the outset. Linear algebra is a pretty big field.

How much of it is GLAS intending to cover?

Alan

> -----Original Message-----

> From: glas-bounces_at_[hidden]

> [mailto:glas-bounces_at_[hidden]] On Behalf Of Edwards, Harold C

> Sent: Friday, February 04, 2005 9:34 AM

> To: Generic Linear Algorithm Software

> Subject: RE: [glas] summary: auto-resizing vectors in assignment

>

> >

> > The discussion on auto-resizing (or not) vectors in an

> assignment are

> > very intense so I tried to summarize the discussion on

> following page:

> >

> > http://www.femtown.org/glas/doc/auto_resizing_vector_on_assign

> > ment.html

> >

> > Please let me know if there are some points that I did not

> cover (we

> > had some discussions in circles and the same argument was given in

> > different forms and thus finally the total list of pro's for one or

> > the other approach are still limited). I will add

> additional arguments

> > to this page (so that you don't have to go through the archives the

> > whole time).

>

> More thoughts after sleeping on this topic ...

>

> Concepts:

> - VectorSpace

> - VectorSubspace

> - Reassigning (morphing) a vector among VectorSubspaces of a

> VectorSpace

>

> Two trivial but illustrative examples:

>

> The VectorSpace of a 'std::vector<double>' has elements that

> are 'double' and dimension of 'max_size()'. A particular

> instance of a std::vector<double> lives in a subspace of

> dimension 'size()'. The assignment operator 'x = y' actually

> does two operations: (1) reassigns the subspace of vector 'x'

> to the subspace of vector 'y' and then assigns the value of

> 'x' to the value of 'y'.

>

> The VectorSpace of a 'typedef double Coordinate[3]' has

> elements that are 'double' and a dimension of '3'. Such a

> VectorSpace does not explicitly define/support subspaces.

>

> Design notions:

>

> The definition of a VectorSpace should include specifications

> for the subspaces that it supports, probably through a

> parameterization as illustrated by 'size()'. More complex

> VectorSpaces could include specifications such as whether it

> is the Cartesian product of other VectorSpaces (i.e. a

> matrix) or the size of parallel-distributed partitioning

> (a.k.a. number of processors).

>

> Implementation notions:

>

> A VectorSpace should manage creation and destruction of the

> vectors that live in its space, e.g.

> 'std::vector<double>::allocator_type'. Given the range of

> possible VectorSubpaces (e.g. parallel-distributed vectors,

> sparse matrices, block sparse matrices, parallel-distributed

> block sparse matrices, ...) I hope that GLAS will eventually

> define an API for this notion that is easily understood -

> given an existing understanding of vector spaces.

>

> --Carter

>

>

> _______________________________________________

> glas mailing list

> glas_at_[hidden]

> http://lists.boost.org/mailman/listinfo.cgi/glas

>

>

**Next message:**Andrew Lumsdaine: "Re: [glas] summary: auto-resizing vectors in assignment"**Previous message:**Edwards, Harold C: "RE: [glas] summary: auto-resizing vectors in assignment"**Maybe in reply to:**Toon Knapen: "[glas] summary: auto-resizing vectors in assignment"**Next in thread:**Andrew Lumsdaine: "Re: [glas] summary: auto-resizing vectors in assignment"**Reply:**Andrew Lumsdaine: "Re: [glas] summary: auto-resizing vectors in assignment"