Boost logo

Glas :

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

From: Williams, Alan B (william_at_[hidden])
Date: 2005-02-04 11:58:08

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:

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?


> -----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:
> >
> >
> > 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]