Boost logo

Ublas :

Subject: Re: [ublas] New uBLAS maintainer
From: David Bellot (david.bellot_at_[hidden])
Date: 2010-03-31 03:07:20

Hi Tom,

thanks for your answer.
Wow, big projects in fact. I like your ideas but I'm not sure we would be
able to do that in one day.

1) Ease the use of uBLAS as a standalone library. Being able to easily
> extract uBLAS from boost would help large projects ship with an
> embedded uBLAS version.

This can be easily achieved for any boost library with a tool called bcp
(you can find it in the boost distribution). Among other things it can
extract only the part of boost your project uses and ease the task of
including it directly into your project.

2) Provide open-source, BSD-like, versions of standard linear algebra
> algorithms such as sparse and dense matrix decompositions, matrix
> functions and so on.

That is already on my todo list. I would like in the future to mimic some of
the basic functions of matlab or similar programs.
At lot of things exist in LAPLACK, ATLAS, etc... and we can access to it
through the bindings. However, it is not a bad idea to have such algorithms
in the library too. Then the user will choose which implementation he wants.
Another purpose is to test the ublas with more complex and standardized
examples and provide pedagogic content.
That's all ideas for the time being, because my first task is the

3) Provide a unified API for these linear algebra algorithms with a
> means of easily switching between different backends (basic open
> source implementation included in uBLAS or external "binded"
> implementation). This would make uBLAS usable without external
> libraries but would also allow it to benefit from optimized
> implementations when they are available elsewhere.

Eh eh, of course that is The great idea. I would love to something like this
at runtime :-D
matrix<double> m1 = my_complex_algo();
matrix<double> m2 = my_heavy_algo();
matrix<double> m3 = my_super_secret_algo();

Let seriously think about it and see what is really feasible. But, hey, why
(more plausible to work with some kind of conditional compilation, not sure
More seriously, integration of different computational backends (well,
bindings) is on the todo list and I want to emphasize the excellent work
that has already been done in boost::numeric::bindings on that topic.

Anyway, all great ideas we'll have to work on.


David Bellot, PhD