From: Dan Elliott (c_reply_to_at_[hidden])
Date: 2006-06-30 18:46:08
Thanks for the reply Gunter. Let's start simply with the three questions listed at the bottom of this message...
>>>>> "Gunter" == Gunter Winkler <guwi17_at_[hidden]> writes:
Gunter> On Wednesday 17 May 2006 05:26, Dan Elliott wrote:
>> I see that the lu.hpp file has a data type permutation_matrix
>> which inherits from the vector type. However, I would like to
>> discuss the merits of creating a matrix permutation matrix type
>> that would behave more like a matrix (e.g. matrix operators for
>> right and left had operations). Permutation matrices could
>> even fall under a larger family of transformation matrices!
Gunter> It would be very convenient to have a transformation
Gunter> matrix that behaves like a matrix. But for the simple task
Gunter> of solving linear equations the current permutation_matrix
Gunter> is sufficient. The permutation_matrix class does not store
Gunter> the mapping (old index) -> (new index) but a list of swap
Gunter> operations needed for inplace reordering of vectors (or
Gunter> matrices). Therefore we should keep this class - maybe
Gunter> with a better name.
I am interested in a permutation matrix class that could be a specific version of a larger class of transformation matrices. For now, I am mostly concerned with permutation matrices.
In code that uses the class already contained within the lu.hpp file, I have been able to, at times, take advantage of the data representation you describe above. Other times, I use a more traditional representation of permutation matrices. So with respect to permutation matrices, and other highly-specialized types of transformation matrices, I believe that the underlying representation should be highly flexible to suit the particular needs of the user.
>> Operations of other types against this type could have
>> specialized algorithms which take advantage of their particular
>> structure. For example, if T were a permutation matrix, and S
>> were diagonal, the operation transpose(T) * S * T has a
>> predictable structure as it goes from left to right.
Gunter> This would be a very interesting extension because
Gunter> symmetric products are repeatedly requested on this
Gunter> list. I think a new matrix_ternary_expression class can
Gunter> cover all products of this type and can be dispatched to
Gunter> specialized algorithms.
I suppose the discussion of the implementation of such an expression class is contingent upon the answer to the question below.
Gunter> However, I am not sure if this
Gunter> should be part of ublas or at a higher level of
Gunter> abstraction (e.g. some glas frontend).
OK, do matrix_ternary_expressions belong in uBLAS?
What does your question imply about algorithms like LU and some of the other higher-level methods within uBLAS like prod, etc?
Where do you all plan on drawing the line on the functionality of the uBLAS library?