|
|
Glas :Re: [glas] summary: auto-resizing vectors in assignment |
From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2005-02-07 16:36:47
Andrew Lumsdaine wrote:
> What is of primary importance in generic programming is classifying the
> requirements on types that are induced by algorithms that comprise the
> library. Algorithms must come first. Then the minimum requirements
> that they have for their (parameterized) types must be analyzed and a
> corresponding framework of requirements created (aka concept hierarchy
> or lattice).
I think one of the main goals of GLAS should be to provide a generic
interface specification containing support for all BLAS operations. The
GLAS should be able to support the development of generic libraries
similar to (P)ARPACK, Aztec, BLZPACK, ITL, (Sca)LAPACK, PETSc,
SuperLU(_DIST), TSFCore, etc.
The generics should allow:
_ mixing dense and sparse containers
_ structured matrices (symmtric,hermitian,skew-symm,...)
_ views (ranges,slices,indirect,...)
_ containers to be stored on the heap,stack and out-of-core,
_ containers to be distributed (over multiple processes)
_ bindings to 3rd party libraries such as (tuned)BLAS, LAPACK, PETSc, Aztec,
_ efficient expression evaluation (blocking, expression-templates,
automatic use of optimised kernels to evaluate (sub-)expressions,...)
Important design goals are performance,flexibility and ease of use.
Since we target to provide a reference implementation in C++ for the
GLAS interface, we target to provide a multi-platform library but above
all C++ standard compliant.
For instance direct support for stencil operations (like Blitz++ does)
in IMO out of scope. The generics again however should allow to add them
without inducing a penalty.
The use-cases or algorithms for which GLAS could be used are thus
enormous. However indeed it would be good to stipulate in more detail
the goals we want to achieve and what operations we want to support.
Next we should not wait too long before discussing the main concepts.
While defining these concepts all members of the ml have their use-cases
in mind and I'm sure they will react whenever a concept does not match
with their use-case.
For instance, one might want to use it for implementing an assembly
routine for a direct symm. solver. This can easily be done using an
indirect view on a symm. matrix. So by having indirect generic views,
GLAS supports this use-case.
>>>
>>> More thoughts after sleeping on this topic ...
>>>
>>> Concepts:
>>> - VectorSpace
>>> - VectorSubspace
>>> - Reassigning (morphing) a vector among VectorSubspaces of a
>>> VectorSpace
>>>
>>>
>>> --Carter
>>>