Boost logo

Boost :

From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2004-07-06 05:42:33

On Monday 05 July 2004 22:59, David Abrahams <dave_at_[hidden]>

> > Almost all the major reference works on BLAS and Matrices
> > simply state elements are either Real or Complex and are therefore
> > implicitly a field.  
> We're not just concerned about the elements of matrices, but the
> vectors and matrices themselves.

OK I was assuming you were looking for a clear concept definition for the
element types.

> This becomes a real issue when you
> have to write algorithms that might operate on matrices of reals or
> matrices of matrices -- yes, these things do come up in real
> applications.

This is very odd. In linear algebra there is no such thing as a matrix of

This impacts on the while prod/operator* controversy.
That is, the primary advantage of not defining operator*. It prevents you
passing matrix to an algorithm (not necessarily part of the uBLAS itself)
that uses operator* and not unreasonably makes the assumption that operator*
is commutative. The assumption is not unreasonable as all built in types
operator* is exactly commutative.

That said I have also argued in favour of operator* instead of prod in the
past. It's central role in LA certainly argues in favour of using operator*.
This involves so much peoples expectation as for algebraic notation,
programming practice and just personal taste.

> >> * Redundant specification of element type in matrix/vector storage.
> See my reply to Toon.

Ah yes value_type is specified in both the matrix vector and storage type
parameter list. In itself this is not good as the storage type should
parameterise the matrix/vector with the value_type. It is simply there to
make the syntax in the default case simple without the need for a type
generator as in MTL.

> > For std::slice (valarray) compatibility stride should be last. Not sure
> > this was not picked up on a long time ago!!
> > valarray (and uBLAS) use size (not end) for good reason however.
> ...which is...?

The begin end definition fails when stride==0. Slices of finite size with
stride==0 are very useful. Similarly when (end-begin) *stride <0 the
behaviour would have to be defined.

> > Interesting solution. Agreed, the current implementation is closed to
> > objects because of the intrusive base class. Sadly uBLAS was designed
> > enable_if. Any pointers to compile/runtime effects of the enable_if
> I can't really imagine what you're asking for here.

I was looking for any publications/links to compare how compilers do between
the two solutions. Anyone have any pointers?


Michael Stevens Systems Engineering
Navigation Systems, Estimation  and
                 Bayesian Filtering

Boost list run by bdawes at, gregod at, cpdaniel at, john at