Dear David,all of the thins you poin out are nice ... if i could add something to the wish list i woul like to add a few items:
1 - please mantain some sort of backward compatibility for people that do not use internals... functions as noalias, prod innner_prod etc, while not strictly needed do not make any harm and maintaining them woul make people's life easier in the migration...
2 - clearly separate where openmp is going to be used (for example sparse and large dense matrices) and where not ("tiny" matrices both in stack and heap). this is important as one needs to avoid nested openmp parallelism
3 - it would be nice to have more c interoperability with the internals of sparse matrices. this would make much easier to wrie wrappers
4 - consider pastix as a direct solver apart for mumps. it is really good and actively developed...
good luck with your effort
ciao
Riccardo
On Sat, Dec 7, 2013 at 11:38 AM, David Bellot <david.bellot@gmail.com> wrote:
Hi,
it has been a long discussion we all had for many months now. Should we rewrite ublas from scratch or simply improve it.
Joaquim and Oswin wants a brand new ublas
Nasos was more in favor of improving it.
I personally find very exciting the idea of writing something new, but ublas is very well known now. On the other hand, Eigen and Armadillo took the crown of the main C++ blas library in users' hearts.
On my todo list for ublas, there are things that will require ublas to be deeply changed. At this stage, we can almost talk about a new library.
Christmas is very close now, so maybe it's a good time to start talking about the features we wish for ublas and see if they can be implemented with the current version or if a new uBLAS 2.0 is necessary.
After all, Boost::signal did the same a few years ago. We can definitively do the transition.
I begin:
- unified representation of vectors and matrices to represent the fact that a vector IS a matrix. Matlab does the same
- automated use of different algorithm to let the compiler "chooses" the best implementation (if possible) and switch on SSE, distributed or whateve we need
- implementation of solvers and decompositions algorithms
and this is what Nasos and I think should be integrated too:
1. Matrix multiplication
2. Algorithms infrastructure (so that we can have real useful features)
3. 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
4. NEW DOCUMENTATION - examples and the rest
5. Incorporate some critical bindings (i.e. mumps bindings which is currently probably the most efficient smp and distributed open source linalg solver)
6. matlab binding?7. distributed ublas
Please add and ESPECIALLY, please tell me your view on the current infrastructure of uBLAS. It seems many people are not happy with the current "expression template" grammar.
I'm open to everything
Best,
David
On Thu, Dec 5, 2013 at 11:14 AM, Joaquim Duran <jduran.gm@gmail.com> wrote:
I think that al stuff pending of merge listed by David, should be merged and migrate to uBlas 2.0 and while uBlas 2.0 is in development/maintenance then design from scratch uBlas 3.0.
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: rrossi@cimne.upc.edu
--
Dr. Riccardo Rossi, Civil Engineer
Member of Kratos Team
International Center for Numerical Methods in Engineering - CIMNE
Campus Norte, Edificio C1c/ Gran Capitán s/n
08034 Barcelona, España
Tel: (+34) 93 401 56 96
Fax: (+34) 93.401.6517
web: www.cimne.com
_______________________________________________ ublas mailing list ublas@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: athanasios.iliopoulos.ctr.gr@nrl.navy.mil