Gutner has done a great job over the past years and I find great relief in the fact that somebody can spend some of his (understandably hard to find) time into the continuation of this great project.
Thank you for the taking all the future load, that based on your plan may turn out to be pretty heavy :).
Some discussion on the project ideas:
1. Optimal (or near optimal) Sub matrix read/write access through an elaborate interface will be great. All of who have worked with numpy or matlab can understand how clean code can be with such a feature.
2. Basic implementations are necessary in an extension framework, especially for the newcomers. Bindings are the way to go though for more demanding applications. (I cannot imagine rewriting a solver like MUMMPS or PARDISO in uBlas).
3. Gpu part: Reference enabled Abstract Syntax Trees (the static template meta-programming trees that are created by ublas to evaluate expressions) are not a well candidate for GPU implementations. Furthermore I find that the computational gain in algebra (even for dual TESLAs) is no that dramatic compared to an i7 system running MKL (for double precision arithmetic). I suppose this will change with FERMI architecture (projections show a 50x increase over current CPU in double precision). Finally since openCL is not yet well supported (only Apple has a decent implementation), it is difficult at this point of time to provide a good design. Time is coming that all those will be available though!
4. I would vote for prod(A,B) and probably for an element wise product function as well (ew_prod or similar). I think tweaking the current product implementation to deal with some cache locality issues will provide an optimum result (it is already close to but not there yet, depending on row and column majority of the matrices involved). In addition see (8) below.
5. Totally agree
6. I also find important that some tutorials or implementation examples are gathered in a single resource.
A few more items (Some may be quite laborious):
7. An interface for parallel processing (or some examples of how people are using parallel processing with uBlas).
8. SSE instructions (this is hard and may need to change some of the uBLAS back-bone, since the current refed ASTs implementation does not cooperate well with meta-programming type vectorization).
9. Fixed size vectors and matrices ( I have an alpha implementation, but I was stuck in the need to change some of the uBlas inner workings to make this optimal).
10. Matrix and vector views (following STL's range concept) in the spirit of Generic Image Library views (Gutner has started working on something like that).
11. Adaption of boost.assign for filling ublas containers.
Best Regards
Nasos
From: david.bellot@gmail.com
Date: Sun, 14 Mar 2010 21:44:51 +0100
To: ublas@lists.boost.org
Subject: [ublas] New uBLAS maintainer
Dear uBLAS users,
recently Gunter Winkler asked for someone to take over the maintenance of the uBLAS library. As a fervent user of uBLAS and a strong believer in Open Source and Free Software, I decided to propose myself as the new duty man. I will therefore have the honor to be in charge of uBLAS and will do my best to make uBLAS reach its goals of versatility, performance and ease of use.
Let me quickly introduce myself: my name is David Bellot, I hold a PhD in Computer Science and do research (currently in the finance world) on Machine Learning and probabilistic artificial intelligence, hence my strong interest in uBLAS.
First of all, I want to say a big Thank You to Gunter for all the great work he did on uBLAS and a personal Thank You to help me getting on-board and starting my new duty as uBLAS maintainer.
I would also like to talk about potential projects for the next versions of uBLAS. For that purpose, I hope everybody will be interested in bringing new ideas, wishes and even new pieces of code:
(1) as you can imagine, in machine learning, one often needs to "randomly" access to sub-matrices. A good framework is already in place for matrix_view, I would like to extend it so that to make it as versatile as it is in other libraries or even Matlab.
(2) after reading last week emails, I think we could provide basic
implementations of a few standard algorithms like inversion, solvers, etc...
(3) bindings are a hot topic. Let's be pragmatic: it's not supposed to
be part of uBLAS but having a standard interface would add a strong value to uBLAS. And, I am like others, I want to play with my brand new nVidia card.
(4) another hot topic which is a recurrent complain about uBLAS: the product of 2 matrices. Do we want prod(A,B) or A*B. Let's think about it because other libraries implemented A*B in a very efficient manner too.
(5) Bindings for big libraries are also important and subject to discussion. I think we have to work more on the interface between all standard libraries when it is needed because, at the end of the day, people also want to use uBLAS to make computations with existing standard and not just write brand new algorithms.
(6) I will join Gunter in his effort to provide new documentation, covering more topics, with tutorial and advanced topics. uBLAS is a great library and a good documentation is of primary interest. That is one of the most important topic for me (yes, way more than prod(A,B) versus A*B)
Please everybody contribute with your own ideas and desiderata.
Let's work and make uBLAS simply the best.
With my Best Regards,
David Bellot
--
David Bellot, PhD
david.bellot@gmail.com
http://david.bellot.free.fr
The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started.