Boost logo

Glas :

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

From: Edwards, Harold C (hcedwar_at_[hidden])
Date: 2005-02-04 11:33:56


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