|
|
Ublas : |
Subject: Re: [ublas] Patch/proposal for overloading operator * in ublas
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2009-09-10 02:31:03
Gunter Winkler wrote:
> But this raises again the question: Why do we need so many different
> linear algebra libs? Shouldn't we simply freeze uBLAS and slowly switch
> to MTL4 (http://www.osl.iu.edu/research/mtl/mtl4/, which is already
> quite powerful and uses state of the art programming methods)? The
> complete redesign of the template machinery would take weeks of a full
> time developer - however there is no one right now who can take this
> task. There is even a good lib for small matrices available:
> http://tvmet.sourceforge.net/
After severals years of struggling with these libs, I've learnt that there's
not one answer :-). All of them seem to want to do too much: provide the
containers, expressions, and algorithms.
IMHO, a better road would be the following.
1) Start with the uBLAS containers as a separate library, and give it a nice
name. Remove stuff from the containers that has anything to do with template
expressions. Define a rich set of traits that ensures good accessibility and
extensibility. Improve on the containers, just to name a few:
* provide algorithms that help users filling the containers with useful
data
* add a few missing matrix types, remove a few if needed
* rename size1 to, e.g., col_size, etc.
* improve the costs of matrix resizes
* full serialization / pretty printing / etc. support
* support compile-time fixed-size containers
* support mixed-memory models (RAM / RAM of GPU board)
* support distributed / parallel containers
This would be enough for one library, wouldn't it?
2) Take the uBLAS expressions are they are after some revisions that have
been suggested. Provide a reference implementation for these expressions.
Make them easy to code against and extend with own functionality: rewrite
based on Boost.Proto. Create a plugin archhitecture that enables expression
tree inspection and rewrites. This is certainly worth a library, too.
3) Have developers contribute all kinds of algorithms: based on 2), but also
conforming to 2). I.e., an algorithm has to provide enough traits /
information so other extensions can build on those. E.g., LAPACK bindings.
That's about it :-). If I've fully missed a particular type of important
user, I'd be happy to hear about it.
Cheers,
Rutger