|
|
Glas :Re: [glas] summary: auto-resizing vectors in assignment |
From: Andrew Lumsdaine (lums_at_[hidden])
Date: 2005-02-04 13:08:00
As I mentioned in a previous mail, discussing what a vector class
"should" or "shouldn't" have at this point is quite premature.
What is of primary importance in generic programming is classifying the
requirements on types that are induced by algorithms that comprise the
library. Algorithms must come first. Then the minimum requirements
that they have for their (parameterized) types must be analyzed and a
corresponding framework of requirements created (aka concept hierarchy
or lattice).
I think this approach obviates in some ways the discussions about what
a particular data type should have or not. In a generic library, there
are no data types per se. There are concepts, which describe the
requirements that types must fulfill in order to work with algorithms
in the library. And there are models of those concepts, particular
types that meet those requirements.
So I think the first question here is: What are the algorithms that
need to be supported? What are the requirements on types for those
algorithms? If resizing, e.g., is *required* by some algorithms, then
resizing should be part of an appropriate concept in the library. If
not, then not.
Best,
Andrew Lumsdaine
On Feb 4, 2005, at 11:58 AM, Williams, Alan B wrote:
>
> 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
>>
>>
>
>
> _______________________________________________
> glas mailing list
> glas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/glas