I would just like to make a few remarks
here. I also integrated some of the ideas that people posted on
the list up to now.
On 12/07/2013 05:38 AM, David Bellot wrote:
This is not correct. I only suggested that in order to be able to
meet the GSOC deadlines.
Since I aided in compiling this list I will just point out some more
details on the basic features I believe uBLAS 2.0 should focus on:
1. Expression templates mechanism rewrite : probably go with
boost::proto
2. Unified matrix - vector classes. We could even make this a tensor
super-class that I would prefer in the end. The critical issue would
be to make a graceful traits model (maybe a traits object that
bundles together all relevant information, rather than a bunch of
properties the current traits model support)
3. Separation of data storage from matrix/vector/tensor classes to
break the current monolithic model and enable interoperability with
other libraries (i.e. graphics, storage, gui, algebra, etc.). A
model like what is used in boost::gil is very appealing to me. Doing
that for example would be ultra easy to make an ublas/octave/matlab
wrapper.
4. Parallel implementation: The C++11 threading model can be adopted
instead of openMP. It will be a little bit more involved to setup
and it may require some state in the form of a singleton. To avoid
this we will need some sort of interface to initialize threads pools
and provide algorithms with the thread data.
5. Distributed uBlas. I consider this critical since it seems that
large computations will move to clusters in the future (especially
with the availability of all those inexpensive cloud computational
cluster services).
6. Algorithms infrastructure (from fast BLAS to general purpose
algebra and beyond): I think this is very critical.
7. DENSE MATRIX MULTIPLICATION: We already have a good
implementation from GSOC, that needs some face lifting before it
gets into production.
8. Bindings (Migration of the current ones and extension to other
popular packages like MUMPS, PARDISO and other solvers)
9. Enable syntax similar to MATLAB or even extend it by using
summation convention and Einstein notation. Under such a model,
algorithms will be ultra easy to write (although in many cases not
optimal with respect to the CPU architecture). Imagine for example
the multiplication:
ublas2::index i,j,k;
A(i,j) = B(i,k)*C(k,j); // Automatic looping over i,j and summation
over the rhs 'k' index.
and that would be it!
// note indexes can be reused since they are merely placeholders
ublas2::index m(1,10);
A(m,j) = B(m+20, j)*C(m,j);
For such a plan the critical path would be:
0a. Decide what type of data uBlas will be operating on and start
with the traits mechanism. Because all algorithm dispatching will be
based on it it should be carefully designed. Of course a very first
trivial interface would be to build on top of the current one:
typedef ublas2::matrix<double> my_matrix:
typedef my_matrix::traits traits;
with
template <typename Storage, typename Orientation, std::size_t
Order>
struct traits {
typedef Storage storage_category;
typedef Orientation orientation_category;
static constexpr std::size_t tensor_order = Order;
}
0b. Make sure the traits model is easily extendable
1a. Dense tensor_view class and appropriate template specialization
for matrix and vector classes that people are more accommodated
with. Do not forget static containers!
1a. Sparse tensor_view and template specialization for matrix and
vector classes if applicable. Otherwise implement only specialized
sparse containers.
1b. tensor, matrix, vector classes (own data instead of views,
probably wrap around views)
2a. Development of new expression template mechanism and
introduction of computational kernel concept alongside with threaded
implementation.
2b. Range and/or Summation convention/Einstein notation mechanism
3. Everything else.
Ideas/thoughts are welcomed.
-Nasos
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: athanasios.iliopoulos.ctr.gr@nrl.navy.mil