Hey David,
the whole problem of most numerical packages, IMHO, is that everything is tied together. I would encourage a very loosely coupled system. I.e., a system that maybe even would be able to switch storage layout, algorithms, etc., at run-time, maybe following some simple numerical tests. Of course, only if this would be enabled at compile-time.
Data storage and manipulation should be fully loosely coupled, from low abstraction to high abstraction:
* the storage of data. This is about memory-efficiency, and hence, speed of computation. Storage engines might be linear, sparse, etc..
* functional shape of the data. Dense, triangular, etc.
* numerical properties of the data. Positive definite, etc.
* loading and saving the data. Why not support a whole bunch of data-formats
* unified matrix/vector view on the data
* procedural manipulation of the data, shallow views on the data, views on views, etc.
Algorithms should be loosely coupled, too, from low abstraction to high abstraction:
* execution / memory models (synchronous, asynchronous, single core, multi-core, shared memory, distributed memory, GPU memory)
* computational kernels (own C++ CPU-optimized implementations, openblas, atlas, gotoblas2, lapack, mumps, opencl, cuda, fft, etc)
* expression trees, syntax of expression trees (Boost.Proto stuff)
* optimal assignment of computational kernels to expression trees (maybe partly at runtime!)
* being able to extend the expression tree machinery (e.g., with hooks) with own algorithms
Maybe a new library name would be appropriate?
Cheers,
Rutger
On 2013-12-07 11:38, David Bellot 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
_______________________________________________Sent to: marco.guazzone@gmail.com
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas