Re: [glas] concepts, algorithms etc
From: Andrew Lumsdaine (lums_at_[hidden])
Date: 2005-03-11 10:56:54
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
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.
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.