
Boost : 
From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 20040706 05:42:33
On Monday 05 July 2004 22:59, David Abrahams <dave_at_[hidden]>
wrote:
> > 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
matrices.
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
why
> > 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 (endbegin) *stride <0 the
behaviour would have to be defined.
> > Interesting solution. Agreed, the current implementation is closed to
other
> > objects because of the intrusive base class. Sadly uBLAS was designed
before
> > enable_if. Any pointers to compile/runtime effects of the enable_if
solution?
>
> 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?
Thanks,
Michael
 ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk