## Glas :## RE: [glas] Vector Spaces vs. "Objects called vectors" |

**From:** Ian McCulloch (*ianmcc_at_[hidden]*)

**Date:** 2005-02-03 19:49:21

**Next message:**Rainer Blome: "Re: [glas] Design Principles"**Previous message:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**In reply to:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Next in thread:**Toon Knapen: "Re: [glas] Vector Spaces vs. "Objects called vectors""

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

**Next message:**Rainer Blome: "Re: [glas] Design Principles"**Previous message:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**In reply to:**Edwards, Harold C: "RE: [glas] Vector Spaces vs. "Objects called vectors""**Next in thread:**Toon Knapen: "Re: [glas] Vector Spaces vs. "Objects called vectors""