[boost] Re: uBLAS formal review

From: Michael Stevens (support-1_at_[hidden])
Date: 2002-06-26 19:58:50

I vote thta uBLAS should be accepted into Boost.

Hopefully that makes it easy for the review manager!

Let me contiue with a few review comments. I have structured them so I
remember to answer all the questions suggested in the review procedure!

      * What is your evaluation of the design?

uBLAS is elegent!
It's use of expression templates provides the basis for a clean syntax
and efficient evalution structure. The matrix/vector expression syntax
defined provides a natural and expressive mechanism to describe BLAS
operations. Certainly for dense/packed matricies uBLAS provides a
consistent and sufficient set of types and algorithms to operate on
those types.

The class templates that define the expression templates structure
provide an added bonus. They provide a effective way to define function
template paraneters which match specific expression objects. An open
issue is whether the design is open to extension. Can the expression
template scheme be easily extended and expression evalutation enhanced
for these additions?

It seems 2D iterators, such as that required for matrices, are a thorny
issue. Certainly the approches taken by MTL and uBLAS differ
significantly. MTL iterates over 1D objects, uBLAS always over
elements.  Having both iterator1 and iterator2 takes a bit of getting
used to. However but the sementics of this design work well.

Of particular value to me is that uBLAS objects have value semantics.
This makes using the objects with other algorithms safe and intuative.

I would hope that someone else can comment on the design regarding
sparse matrices.

      * What is your evaluation of the implementation?

The code is well structured and and highly readable (if template C++ can
be readable!). It is portable; it even compiles with VC6! The
implementation clearly makes a significant effort at efficient
compilation and execution. Certainly with VC7 dense matrices perform
well, with little "abstration overhead". It seems however there is
significant variability on other compilers!
There are probably many area where the implementation could be made more
efficient. For example the algorithms used for large column_major
matrices have poor locality of reference. Fixing this would require
adding additional dispatch logic and algorithms that iterate linearly
over the column_major orientation. Alternatively assignment algorithms
for same orientation matrices could be performed by vectorisation.

      * What is your evaluation of the documentation?

At present this seems to be uBLAS's major weakness. The individual
features are fairly completely documented but often lack explanation and
meaningful examples. There is a great deal of information regarding the
concepts and structure of uBLAS that needs to be explicitly documented.
For this part of the documentation it would be worth considering using
Bill Kempf's structure and templates.
I like the sections on the uBLAS syntax required to perform BLAS
operations, and also the efficiency and timing results. However they may
be better placed in there own pages.
If uBLAS is included into Boost I would hope that some of this
documentation could be contributed by the community.

      * What is your evaluation of the potential usefulness of the library?

Obviously I think Linear algebra is important! It is used in many area
of computation including graphics (transformation etc), digital
filtering and estimation. The ubiquity of BLAS implementations shows
that this was important in the 70s and I believe and updated approach
using C++ is equally important.

      * Did you try to use the library?  With what compiler?  Did you have
        any problems?

I used most of uBLAS except sparse matrices with VC6 and VC7 and GCC3.1
with good results.

VC7 does have problems running out of heap space when compiling debug
configurations of uBLAS. The /Zm option is needed to set a larger
memoery allocation. However either a compiler memory leak or bug related
to handling /Zm prevents this from working when the same instance of the
compiler is used to compile many files requring larger memeory
allocations. I find a /Zm150 is sufficent to compile individual files.
To work around the second problem the value of /Zm should be varied for
any file that has problems. That is if file1.cpp and file2.cpp both
require a non default /Zm value then file1.cpp should be compiled with
/Zm151 and files2.cpp with /Zm152 etc. This forces new instances of the
compiler to be used for each of these files!
VC7 with the option /Za (ANSI/ no Mircosoft extension) also produces the
warning
..\uBLAS\banded.h(65) : warning C4224: nonstandard extension used :
formal parameter 'lower' was previously defined as a type
Does anyone know if this is just a fantisy of VC7? If this restriction
on formal parameters is in the C++ standard then I have never seen it
before and no other compiler enforces it. Any one know?

      * How much effort did you put into your evaluation? A glance? A
        quick reading? In-depth study?

I've tried to give uBLAS a fair evaluation. To do this I decided to port
a large filtering library that uses MTL to use uBLAS as well. So, after
a week of work on the code, an MTL iterator emulation layer, and using
the uBLAS documentation I hope I have done it justice!

      * Are you knowledgeable about the problem domain?

I use numerical techniques and linear algerbra all the time for my work
on Kalman filters etc

Michael Stevens