|
|
Glas :RE: [glas] Vector Spaces vs. "Objects called vectors" |
From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-02-03 19:49:21
On Thu, 3 Feb 2005, Edwards, Harold C wrote:
> Perhaps we can frame the "resize" concept in the
> broader sense of "reassign vector space."
> Some vector-implementations can be "morphed"
> among a parameterized family of vector spaces while
> other implementations are restricted to their initial
> vector space.
> Whether the vector-implementation is "morphable" should be
> an observable characteristic of its implementation.
> I don't believe it is a matter of whether or not to allow
> "morphable" vector-implementations, but a matter of how best
> to define and manage this characteristic.
Ok, but can you provide an example where it is necessary to manage the
"morphability" of a vector in a non-trivial way? (ie. anything other than
via its assignment operator).
>
>
> > OTOH, partitioning and structure
> > certainly are relevant and need to be included at some level in the
> > concepts that the vector conform to.
>
> These notions have been extremely useful in other efforts;
> and are partially included in the Trilinos design.
> http://software.sandia.gov/trilinos/.
Right. Ideally, it would be possible to integrate these containers
into the library non-intrusively, so that (for example) an
Epetra_Vector is recognized as a real vector, and the appropriate
operations are specialized on that type (or type/concept combination) to
call Epetra functions. This kind of interoperability sets some
constraints on how the generic algorithms work (no member functions, for
example), but I think in practice it will work OK - I used to think
differently I changed my mind on this, there are far too many useful
container classes out there to want to write replacements for them
all. Proxies can make life easier (and are basically necessary for some
operations), but shouldn't be essential.
In the other direction, integrating pre-existing solvers to work with the
appropriate MTL concepts should be relatively easy - as long as the solver
is generic enough that adaptors can be written to join the interfaces.
Cheers,
Ian