Re: ublas : submatrix with different value_type

From: jhrwalter (walter_at_[hidden])
Date: 2001-12-12 17:22:41

--- In boost_at_y..., Toon Knapen <toon.knapen_at_s...> wrote:
> When I have a numerics::matrix< std::complex< double > > for 
instance, I 
> would e.g. like to create a matrix_range with value_type double 
instead 
> of std::complex< double >.
 
Interesting idea. How do the elements of the sub matrix correlate to 
the values of the matrix? Are you interested in the real part real 
(m) or imaginary part imag (m), m being a sub matrix of a complex 
matrix (pure speculation)?

> This is a feasible extension I guess of the current submatrix-
handling.

Yes, if this kind of sub matrices is not mutable.
 
> The main changes I guess involve :
> 
> member to create submatrix becomes template member.
 
Maybe.

> indexing functions (operator(i,j)) needs static_cast<>
 
Hm. 

> alignment difference of original value_type and requested 
value_type 
> should be taken into account for calculating location of (i,j) in 
> storage array.
> 
> iterators need to convert between the two types on the fly (there 
> recently was a thread on real iterator on containers complex'es and 
> vice-versa.
 
Yep, noticed that.

> The main structural change would be that the non-const indexing 
operator 
> (operator()(size_type,size_type)) would need to return a proxy 
object 
> (because you can't create a non-const complex reference to a 
double).

It seems, that you're interested in a mutable sub matrix.
 
> The question now is, should this functionality be migrated into the 
> current matrix_range or would it be best to define another one (the 
> latter will thus only be able to convert between value_type's and 
the 
> former would stay as it is) ?

I think, I'm currently not able to answer this question.
 
A couple of spontaneous ideas (all assuming that you are interested 
in real & imaginary parts):
you currently could use .5 * (m + conj (m)) to get the real and .5 * 
(m - conj (m)) to get the imaginary part, for example (this is not 
efficient ;-). We also should consider defining deferred evaluated 
functions real() and imag() for vectors and matrices using the base 
type of std::complex. 
 
If you need to replace the real part of a complex matrix, things will 
become more difficult.

Regards
 
Joerg