Boost logo

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 (, 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:

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
 * 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.