Boost logo

Boost :

From: boost (boost_at_[hidden])
Date: 2001-11-29 17:42:40


On Thursday 29 November 2001 22:48, walter_at_[hidden] wrote:

> > -> Is it correct, that the diagonal elements are of the
> > same type as the off-diagonal elements, or have I missed
> > missed something?
> Yes, all elements are complex (if value_type is complex<> ;-).
> > I'd prefer the diagonal elements of a complex hermitean
> > matrix to be real. Or at least to have a function
> > returning the diagonal elements as real values.
> How would you design the corresponding iterator interface using real
> diagonal elements? Shouldn't we better assert, that imag (m [i] [i])
> == 0? I'll think about an special accessor for diagonal elements.
In my own matrix package I did the following:
   1) a special function that return diagonal elements, e.g. return type
double for complex<double>
  2) the element access through
    F& HermitianMatrix::operator(const i, const j)
    is only defined for i<j

  but I had no iterators defined :(, so I think a special accessor
  for diagonal elements is the way to go.

> > -> In the same spirit one should not be allowed to
> > multiply a complex hermitean matrix with a non-real
> > scalar, or at least this shouldn't return a hermitean matrix.
> The most critical part here is hermitean_matrix *= scalar. Again I'd
> prefer to assert that imag (scalar) == 0.
But that's sensitive to rounding problems, e.g. if you're writing an eigen
system solver you might create minimal imaginary parts, and you have
to set the explicitly to zero.

> I imagine, that deriving banded_hermitean_matrix (or
> hermitean_banded_matrix :-) statically from matrix_expression should
> give you the neccessary ET support.
> A hint: may be you better try to implement a somewhat simpler form
> like skew_hermitean_matrix ;-) first.
> Thanks for your feedback.

o.k., maybe you're right,
would you be willing to audit/comment my attempts to implement
new matrix types ?

Best wishes

Boost list run by bdawes at, gregod at, cpdaniel at, john at