Hi David,

Yes at a point i thought about contributing to uBLAS. But there are two problems with it that are making it hard to develop.

1. There is no real consensus of what uBLAS should be targeted at. Right now I have the feeling that it should be more or less like Eigen: be applicable to every use case out there. And this is hard. Most of Eigen looks to me like a big mess. This is because it must behave differently in the cases of small, big and very big problems. Right now uBLAS has only a good performance for small dense problems and I am mostly only interested in the middle category. And the last time i proposed changes I got nearly no support but fire from the "small" and "very big" guys. This makes it quite unattractive for me to propose further changes.

2.

So please, feel free to propose anything you think is relevant to uBLAS. At some point we even thought about rewriting a big part of uBLAS and call it uBLAS 2 (and go through the peer review again, etc...). Well, I think uBLAS can evolve smoothly rather than having a big revolution.
I don't think that this is possible without iteratively annoying all uBLAS users who actually use things like loops over matrix elements and the other low level interfaces. I had to rewrite the sparse interface completely(and i am still not sure that i have done that right) as well as the iterator interface. I tried to do it smoothly but I nevertheless broke it 3 times.
The next problem, again sparse, is that there are 3 different formats supported by uBLAS. It is hard to write algorithms for it, because the three formats need to be treated differently. But in a smooth evolution we can't really throw out stuff, especially if there is no 1:1 replacement.
I think you can find such issues in a lot of parts, as you said, uBLAS is old. There are more things, like that you might want to change the way expressions are evaluated so that things like

noalias(A)+=prod(B,C)+D;

are fast and don't require intermediate results in prod().

I think a full rewrite from scratch is required to get rid of all the old burdens. While a review process of course is a bit annoying it might actually help in developing it to something that is actually useful :). (And honestly i doubt that uBLAS as is would pass a review.)

Best,
Oswin

On 29.11.2013 13:55, David Bellot wrote:
Hi Oswin,

well, I'm just the maintainer of uBLAS, not the owner and for sure not the first developer as it was already an old project when I took over it. I believe any contributions is welcome and honnestly so many things can be changed in uBLAS. It's getting a little bit old.
So that's why I'm always happy to have new contributions. That's also the reason I wanted to have GSOC projects this summer and I think it has been a good thing.

I didn't know Shark was your library ! Well done. It's a good library.
I'm especially interested in your implementaion of RBM.

So please, feel free to propose anything you think is relevant to uBLAS. At some point we even thought about rewriting a big part of uBLAS and call it uBLAS 2 (and go through the peer review again, etc...). Well, I think uBLAS can evolve smoothly rather than having a big revolution.

The automatic ATLAS binding is definitively something I want !!!!

Best,
David


On Fri, Nov 29, 2013 at 12:04 PM, oswin krause <oswin.krause@ruhr-uni-bochum.de> wrote:
Hi David,

Thanks for the fast reply. There might be a misunderstanding: I don't have any code here that is ready for uBLAS. The story goes back to approximately spring where it was decided to improve uBLAS. I decided to part ways because of our differences in how uBLAS should look like (and since it is your library it is of course your right to choose!). So I rewrote the whole thing (or better: the parts that i needed, that is dense and sparse algebra, no banded matrices) and now got a 16000 LOC subset of uBLAS with most of the functionality (and sometimes more) and automatic ATLAS bindings for fast_prod etc.

Now i wanted to come back and compare the different approaches and see whether I could adopt some of your changes as well as maybe port some of my code back to uBLAS.

So once most of the new features are there, i would be happy to compare! You would also get a direct benchmark against atlas if you like.

My version is unfortunately not standalone yet because of $REASONS. Also looking at your changes, i doubt that the libraries are compatible, for example because I overloaded op* and op/ for element-wise operations ( I need them so often, element_prod and element_div just does not cut it...)

But if you like you can have a look at it here

(most of ublas functionality minus systems of equations and algorithms)
http://sourceforge.net/p/shark-project/code/HEAD/tree/trunk/Shark/include/shark/LinAlg/BLAS/

(and systems solver + algorithms (wip))
http://sourceforge.net/p/shark-project/code/HEAD/tree/trunk/Shark/include/shark/LinAlg/

Best  Regards,
Oswin


On 29.11.2013 12:40, David Bellot wrote:
Hi,

the latest version is indeed on github. We didn't commit many things this year so far. We are talking (slowly, I must admit, please blame me not the others) about new features and changes:

(1) integrating GSOC 2013 in the main branch
(2) removing the vector object to replace it by a new one that will be a matrix and therefore implement a real row of column vector
(3) Matrix multiplication with operator* valid for all standard operation (vector, matrix, etc...). It is related to (2)
(4) Algorithms infrastructure (so that we can have real useful features)
(5) Matrix/vector views for interoperability <- I think this is ultra critical because now ublas is monolithic in the sense that you have to use it everywhere you manipulate data. This would really help into letting people for example have a list of vectors (they are plotting) and ublas working on top of that to do for example transformations
(6) NEW DOCUMENTATION - examples and the rest. The current one is ... old
(7) Incorporate some critical bindings (i.e. mumps bindings which is currently probably the most efficient smp and distributed open source linalg solver)
(8) Matlab binding? Matlab I/O etc... Well same thing with R, csv files, etc... Bindings and I/O in general are pretty poor
(9) Distributed ublas (GSOC'13)


I'm really interested seeing your benchmark. Maybe you can join the github ublas project as well. If you give me your github id I can associate it with the project and you can push your code. Practically speaking, there is a ublas project on github which is a copy a the main boostorg/ublas project. And there are many branches for each project that people can use.

Links you can be interested in:
https://github.com/uBLAS/ublas/wiki

The workflow that we will follow (as also suggested in boost mailing list) is: http://nvie.com/posts/a-successful-git-branching-model/
with the difference that we have two "masters" i.e. one in ublas_develop (which is our working master) and one that will be always in sync with the latest boost release.

And last but not least, there are a few changes for supporting IDE. In fact, that would be good if people can contribute more. I'm a vi user only, so I need others' skills for that. QTCreator is on its way. Ideally, if we can have some sort of support for the main IDE, on top of my mind: Eclipse, Netbeans, Visual Studio, Anjuta, KDevelop, etc...

Best regards,
David



On Fri, Nov 29, 2013 at 9:04 AM, oswin krause <oswin.krause@ruhr-uni-bochum.de> wrote:
Hi,

I am interested in the current development status of the library. is there the possibility to get the latest version somewhere? I tried to find a working branch on https://github.com/boostorg/ublas but could only find changes older than half a year.

I am interested in Benchmarking the "new" ublas against "my" reimplemented subset (think about my personal summer of code :) )

Greetings,
Oswin
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: david.bellot@gmail.com



_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas

Sent to: Oswin.Krause@ruhr-uni-bochum.de


_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: david.bellot@gmail.com



_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: Oswin.Krause@ruhr-uni-bochum.de