|
|
Glas :Re: [glas] introducing the storage concept, a first interface specification |
From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2005-01-19 09:27:40
Andrew Lumsdaine wrote:
> I would like to suggest an alternative approach to designing concepts.
> In our experience (designing MTL, BGL, etc), concepts should not be
> designed first out of thin air. Rather, one should analyze the
> algorithms of interest in the problem domain, discover the generic
> properties of types these algorithms require to operate (efficiently),
> and then factor those requirements into a concept framework. This is
> generally an iterative process, as the algorithms may be refactored or
> redesigned as the concept requirements are being developed. Algorithms
> really need to come first.
I totally agree with you: every software-project starts with use-cases.
And in the 'problem domain' of Glas, the algorithms are the use-cases.
And instead of defining first some use-cases, I maybe was a bit too
quick and used our experience with developing uBLAS to start the design
of the low level functionality.
>
> As Dave mentioned, we have done this (a few times) with MTL. In MTL,
> two concept domains emerged, one corresponding to mathematical entities
> and one corresponding (roughly) to storage, etc. The former domain
> includes things like ring, field, vector space, etc. Many higher level
> algorithms (such as conjugate gradient, say), only need to work at this
> level. Other algorithms, such as matrix vector product, need to know
> (some) lower-level details of the linear algebra types (e.g., to get
> values or index values out), which is where the storage-related concepts
> come in.
For the design I have proposed so far I not only used our uBLAS
experience but I had also some use cases in mind. However currently I
was only thinking of pretty simple use cases that are similar to BLAS1
operations (that's why I started out with a test-program doing a scal
operation). Directly looking at SVD etc. would make the discussion to
complex to start with IMHO: if one wants to build a house (= use case),
one also starts with laying the foundations before constructing the
roof. With that in mind I started out with a minimal Storage concept. A
minimal concept because indeed as you mention, we can only refine the
concept from the experience we gain with the algorithms that are using
the storage.
>
> We have a number of documents we can provide about MTL. Jeremy Siek's
> MS thesis covers the design of MTL 2. We also have a preliminary design
> document for MTL 3. Both of these are perhaps a little dated at this
> point (we have continued to gain more experience with generic
> programming since we wrote those), but they may make good starting
> points for discussion.
I'm open to all suggestions. Of course it would be good to start from an
existing design instead of starting to design from scratch. So if we can
start from the MTL 3 design, that would certainly be beneficial to the
project (supposing that design is still open to suggestions from the
glas members)
I read some papers on the design of MTL2 long time ago (not sure if it
was Jeremey's thesis because I don't have it around anymore) but I
certainly would appreciate if you could provide us with a pointer to
some MTL 3 design documents.
toon