On Jul 6, 2004, at 5:42 AM, Michael Stevens wrote:
On Monday 05 July 2004 22:59, David Abrahams <dave@boost-consulting.com> 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.
What about a block diagonal matrix?
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 (end-begin) *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 ___________________________________
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost