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