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. 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 ___________________________________
Michael Stevens wrote:
This is very odd. In linear algebra there is no such thing as a matrix of matrices.
Yes, there is. It's a linear transformation mapping a space of matrices to another space of matrices. But could Jeremy or David provide some examples of useful applications of such an object? They are immensely useful in pure mathematics; I would love to know how they arise in more practical areas. Deane
Deane Yang <deane_yang@yahoo.com> writes:
Michael Stevens wrote:
This is very odd. In linear algebra there is no such thing as a matrix of matrices.
Yes, there is. It's a linear transformation mapping a space of matrices to another space of matrices.
But could Jeremy or David provide some examples of useful applications of such an object? They are immensely useful in pure mathematics; I would love to know how they arise in more practical areas.
They're used in numerical simulations in the frequency domain (http://www.cercom.polito.it/Publication/Pdf/28.pdf), and they form the basis for the validity of many blocked matrix operations. The fact that you can view it as an optimization or an operation on a matrix of matrices should mean that you can achieve better code reuse in the library. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
An example use of a block diagonal matrix is when you apply decomposition to model decentralized planning. Each of the independent subsystems can be represented as a matrix on the diagonal... On Jul 6, 2004, at 6:51 AM, Deane Yang wrote:
Michael Stevens wrote:
This is very odd. In linear algebra there is no such thing as a matrix of matrices.
Yes, there is. It's a linear transformation mapping a space of matrices to another space of matrices.
But could Jeremy or David provide some examples of useful applications of such an object? They are immensely useful in pure mathematics; I would love to know how they arise in more practical areas.
Deane
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Jul 6, 2004, at 6:51 AM, Deane Yang wrote:
But could Jeremy or David provide some examples of useful applications of such an object? They are immensely useful in pure mathematics; I would love to know how they arise in more practical areas.
In reply, John Fuller wrote:
An example use of a block diagonal matrix is when you apply decomposition to model decentralized planning. Each of the independent subsystems can be represented as a matrix on the diagonal...
and David Abrahams wrote:
They're used in numerical simulations in the frequency domain (http://www.cercom.polito.it/Publication/Pdf/28.pdf), and they form the basis for the validity of many blocked matrix operations. The fact that you can view it as an optimization or an operation on a matrix of matrices should mean that you can achieve better code reuse in the library.
This is fascinating and somewhat unexpected (at least to me). In other words, there are two different types of matrices of matrices. The two examples above refer to the type, where you have a linear transformation between two direct sums of vector spaces. My message referred to a linear tranformation between two spaces of linear transformations (or more generally, tensor spaces). In the former case, elements of the matrix (of matrices) can have different dimensions. In the latter, every element is a matrix of the same dimension.
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
participants (4)
-
David Abrahams -
Deane Yang -
John Fuller -
Michael Stevens