|
|
Glas :Re: [glas] introducing the storage concept, a first interface specification |
From: Andrew Lumsdaine (lums_at_[hidden])
Date: 2005-01-19 08:18:25
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.
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.
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.
Best Regards,
Andrew Lumsdaine
On Jan 19, 2005, at 2:45 AM, Karl Meerbergen wrote:
> David Abrahams wrote:
>
>> I don't understand why you're reinventing the matrix concept taxonomy
>> when MTL basically got it right to begin with.
>>
>>
>
> I suggest you briefly explain this and give a web page or document
> address with more detailed information.
>
> The discussion about the storage concept should make clear how we can
> easily allow for different ways to store the data without putting much
> storage detail the vector and matrix containers. If this alreasy
> exisits, ok, fine, but then explain it please.
>
> Karl
>
> _______________________________________________
> glas mailing list
> glas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/glas