|
|
Glas :Re: [glas] concepts, algorithms etc |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-03-12 06:31:47
Andrew,
This is all clear to me. Perhaps I was too carried away by the fact that GLAS
stands for generic linear algebra software and that the goal is to develop
linear algebra software.
If there really is a need for a VectorSpace concept, which I can understand in
some situations, e.g. when working with polynomial spaces, ok, fine.
The VectorSpace concept allows for the operations
Scalar * VectorSpace
and VectorSpace + VectorSpace
So, for a vector/matrix library (which GLAS is supposed to become) this allows
for:
Scalar * Vector
Scalar * Matrix
Scalar * SparseMatrix
Scalar * ToeplitzMatrix,
etc.
(Recall that matrices are also members of a vector space)
If the VectorSpace is a Vector or a Matrix, and the value_type of Vector, and
Matrix and Scalar are the same, then we are in the traditional numerical
linear algebra. This is the minimum requirement I want to achieve and I think
many of us. And this is well described in the book by Golub and Van Loan.
The only situation I see where a VectorSpace concept is useful, is when the
value_type of Scalar and Vector (and Matrix) are different. In the other
cases, assuming the value_type is in a field, algebraic vectors and matrices
are members of vector spaces. Tell me if I am wrong.
Even for iterative methods, eigenvalue solvers etc (which happens to be my
expertise), it is not sufficient to define the concepts VectorSpace and
HilbertSpace.
Perhaps we should make a list of very specific examples we would like to
support with GLAS and from this make the required concepts. Otherwise we
continue arguing that we need or need not a VectorSpace concept.
Karl
On Friday 11 March 2005 16:56, Andrew Lumsdaine wrote:
> This question raises an important issue regarding generic library
> development. Designing concepts (and designing for genericity) is not
> the same as designing for base classes. That is, a concept hierarchy
> should reflect the absolute *minimum* amount of functionality necessary
> for the algorithms of interest to operate (and to operate efficiently).
> This allows each algorithm to work with the maximum number of actual
> types.
>
> The idea is not to create a concept as a "grand unified type
> specification" that includes all possible functionality and then write
> all algorithms to take the same types. If an algorithm is specified
> with unnecessary requirements, it will limit its range of
> applicability. That is, one wants a set of algorithms that look likes:
>
> template <typename Monoid>
> void foo (Monoid& z, const Monoid& y, const Monoid& x);
>
> template <typename Field>
> void bar (Field& z, const Field& y, const Field& x);
>
> template <typename VectorSpace>
> void baz(VectorSpace& z, const VectorSpace& y, const VectorSpace& x);
>
> template <typename HilbertSpace>
> void zip(HilbertSpace& z, const HilbertSpace& y, const HilbertSpace& x);
>
> Specifying all of these algorithms in terms of the type with the most
> requirements (e.g,. HilbertSpace) would mean that foo() could not be
> correctly used with types that model Monoid but not HilbertSpace.
>
> Regards,
> Andrew Lumsdaine
>
> On Mar 11, 2005, at 4:23 PM, David Abrahams wrote:
> >> My question is: why do we need a VectorSpace concept?
> >
> > Are there algorithms/functions you'll be implementing that actually
> > require only Vector Space, but not Linear Algebra? If so, you will
> > overconstrain their arguments in the specification by using Linear
> > Algebra in the requirements.
>
> _______________________________________________
> glas mailing list
> glas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/glas
-- ============================================== Look at our unique training program and Register on-line at http://www.fft.be/?id=35 ---------------------------------------------- Karl Meerbergen Free Field Technologies 16 place de l'Université B-1348 Louvain-la-Neuve - BELGIUM Company Phone: +32 10 45 12 26 Company Fax: +32 10 45 46 26 Mobile Phone: +32 474 26 66 59 Home Phone: +32 2 306 38 10 mailto:Karl.Meerbergen_at_[hidden] http://www.fft.be ==============================================