[boost] Re: uBLAS formal review

From: Benedikt Weber (weber_at_[hidden])
Date: 2002-07-01 15:46:48

This is my formal review on uBLAS.

I did compile and run the tests with MSVC6 and Metrowerks CodeWarrior 8. I
was especially delighted that CodeWarrior compiled without error, even
though the authors had no access to that compiler. I also did my own tests,
many of them to learn about things that were not described in the
documentation. In all I spent about five days for evaluating the library. I
tried to not just repeat the given tests, but to perform my own ones based
on what I would expect of a matrix library. However, I did not actually use
the library in any project. I was surprised how flexible the system is: you
can freely mix different shapes of matrices and it handles real/complex
mixed types easily. Having tried to achieve these kind of flexibility with
my own matrix library some years ago, I am really impressed by this
implementation!

I also spotted some weak points of the library. One is a possible problem
with type safety. You can i.e. initialize a triangular matrix by a full
matrix. The problem is not detected neither by the compiler nor at runtime.
The triangular matrix just fills its entries from the full matrix without
noticing that there are more entries on the right hand side. A return type
or some other device should be provided that gives some type safety. Since I
just recently realized the problem, I posted it only today and there was no
time to discuss it yet.

Another problem I found is concerned with expression templates. The way they
are implemented in uBLAS does not give optimal performance for all
expressions. An example is A*(B*v) with A, B matrices and v a vector. This
performs much slower with expression templates than without in the current
implementation. The authors have responded quickly with a fix for that
problem, but I don't know if this is the final solution yet. I do not think
that efficiency of Fortran and machine dependent assembler code can be
reached at this time, but the library should consistently perform better
than trivial home made matrix libraries.

Generally I think this is a much awaited library for many of us. It's
carefully implemented and much work has put into it. One important point is
also that the authors give great support and responded to all questions and
problems promptly. However, there should be additional documentation and
testing. The testing has been too much restricted to the BLAS functions so
far, so some details were missed as the discussion shows.  Problems not
fully solved yet are the efficient evaluation of A*(B*v) and perhaps other
expressions, and type safety. With these reservation I vote yes for
acceptance into boost.

Some additional points:

Documentation
-----------------
* A little more explanation on expression templates would be useful. The
topic is quite involved, so an example on how and when expressions are
evaluated could be sufficient (together with some references).

* The BLAS description is nice but distracting in an introduction. uBLAS is
much more general and the examples should emphasise that fact, rather than
being restricted to BLAS.

* In general, more and more complex examples would be valuable. Not only the
code but also the result could be shown in some cases. Sparse matrices
should not be filled up in the examples.

* There are many different data structures and algorithms that you can
choose by defining macros. It's not easy to see what they are all for, so a
documentation would be helpful. I believe that some of them are used to test
different versions only. If they are kept in the final release, the
documentation could just say that they are not intended for regular use.
This would avoid some confusion.

Additional comfort
----------------------
I would like to see some more functions that make using the library more
comfortable:

* A better output operator with matrices printing in rows and columns. A
matrix with complex numbers is hardly readable in the present version:
[3,3](((0,0),(1,0),(2,0)),((1,0),(2,0),(3,0)),((2,0),(3,0),(4,0)))

* Ranges, rows, columns and other proxies could be made accessible from the
original classes by member functions, such as A.row(i) or
A(range(0,3),range(0,2));

Additional matrices
-----------------------
Not for now, but in the long run, it would be useful to have diagonal
matrices, gather and scatter, and skyline matrices.

* Diagonal matrices are useful for storing eigenvalues and singular values.
LAPACK uses vectors for that, but with vectors you have to code the
multiplication for a matrix/diagonal_matrix yourself. banded_matrix is a
substitute, but I think diagonal matrices deserve their own class.

* It would be nice to have some proxy for indirect access or some gather and
scatter mechanism. I have seen discussions in the mail list archive about
that, but I don't see anything here in the present implementation.

* Skyline matrices (MTL: envelope matrices) are something between banded and
sparse matrices, mainly used in finite elements. Maybe this is somewhat
special for a general library but would be useful for some applications.

-Benedikt