From: Matthias Troyer (troyer_at_[hidden])
Date: 2002-07-01 12:33:29
I would like to add my comments to the ublas review.
First of all I found the ublas authors very quick in responding
to questions, eager to explain things and receptive to new ideas.
This is an important consideration for such a complex package.
Next, I strongly support a Boost matrix library, having seen the
need for one in my own research all too often.
As far as ublas is concerned I want to raise the following issues,
that apply to what I expect of a Boost matrix library and where
ublas might need to be improved, either before acceptance or
1.) I would prefer to be able to write a matrix-vector product
as M*v, without the need to use the prod(M,v) function.
Similarly I would like to be able to write a vector inner product
as something like x.transpose()*y or transpose(x)*y
2.) If a Boost matrix library, such as ublas, wants to find
acceptance in the scientific community at which it is aimed,
performance at BLAS/Atlas level are a MUST. A 5-10%
penalty might be acceptable, but factors of 2 or larger
are a no-go. After all we run our codes on multi-million $
machines, and a factor of two in speed can go into thousands
of dollars (fortunately not real money for most of us, but
one should keep the actual cost of ones' research in mind)
3.) Related to that, we need optimal performance of an expression
like A*B*v, as was discussed by others. All reasonable expressions
a user might write should be near-optimal in performance for dense
4.) Finally, there is one other essential issue: extensibility of the
library. I need to be able to interface my own data structures for
vectors and matrices. Often we need to take a data structure provided
by another library as matrix or vector. If it is not possible to use
them directly, it should be easy to write wrappers, adn this should
be documented well and examples given.
5.) Interfaces to LAPACK calls at least for dense matrices.
If a Boost matrix library fulfills criteria 2-5 (criterion 1 is
nice-to-have but a must) I can envision using it myself and endorsing
it for other large-scale scientific code developments that are
currently being started and where I am partially involved.
If performance and extensibilty are not guaranteed, ublas would
remain just-another matrix library and would not be able
to be establish itself as a standard.
My sincere wish is that the Boost matrix library will be efficient
and flexible enough to become the long-missing standard and I urge
the ublas authors to seriously think about the performance issues
that were already raised by others. I would love to switch to
a Boost matrix library as soon as possible, would use it
in all my research code, and also in my lectures and student
I also hope that the ublas authors can turn ublas into such
an efficient library and would then vote yes for inclusion into
boost. If however, the performance problems cannot be solved
at this time I would rather wait another year for a better
solution than to get an inefficient Boost matrix library now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk