Re: [boost] uBLAS formal review

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-01 14:00:38

I want to start by apologizing for not giving the time and thoroughness it
deserves to my review of uBlas. I hope that the other commentary I've made
during the review period helps to make up for that.

I think this is an important contribution for Boost and the community. I
agree with most of Matthias' comments below, with one important difference:
I think we should accept the library, provided that the authors intend to
continue energetic work on it. C++ numerics libraries have come and gone...
but mostly they're dead because the authors have not maintained them. As an
accepted Boost library, uBlas would receive the users and public attention
that such a project requires to keep it moving. However, I also want to
stress that there's still a lot of work to do. Numerics users are an
uncompromising bunch, requiring both expressivity and maximal efficiency.
Matthias' list goes to the heart of the matter. Fortunately, most of these
problems have been solved by other C++ numerics libraries, and I urge the
uBlas authors to capitalize on the work of those who have come before. Also
I agree with another poster that the documentation needs work, and that
this will be crucial to acquiring the momentum and user-base this project
needs.

-Dave

From: "Matthias Troyer" <troyer_at_[hidden]>

> Dear Boosters,
>
> 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
> shortly thereafter:
>
> 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.

I'm very confused. Is prod() really neccessary?!

>      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
>      matrices.
>
> 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
> projects.
>
> 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.
>
> Matthias
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>