Are iterators defined over Triangular Matrices?

[GK Palem]

Came across this situation of having to use an iterator for a StrictlyUpperMatrix and got confused over the semantics.

typedef StrictlyUpperMatrix<DynamicMatrix<int, blaze::rowMajor> > TMat;

    for (size_t i = 1UL, iMax = n; i <= iMax; ++i)
    {
        for (TMat::ConstIterator it = m.cbegin(i) + 1, end = m.cend(i); it != end; ++it)
        {
          ...
        }
    }

Does it go over all elements or just the triangular portion of the elements?

The documentation does not touch this point, and in practice I am getting some segfault exceptions in some scenarios.

Question:

• Are iterators defined for Triangular Matrices?
• If not, is it possible to raise compile time errors (and hence prevent their usage)?
• If yes, what is their behavior? Do they traverse only the triangular portion of the data or complete row/column?

‌

[Klaus Iglberger]

Hi GK!

Yes, iterators are defined over triangular matrices and have well defined behavior. As the wiki explains, dense triangular matrices store all elements, including the zero elements (else performance would suffer). Thus iterators also run over these elements (again, else performance would suffer). Just as you are not allowed to write these zero elements via direct access (i.e. via operator()), you are not allowed to write these elements via iterators. In case you try that, you'll get an exception. Reading, however, is always possible. The blazetest covers all possible cases.

I hope this answers your questions,

Best regards,

Klaus!

[GK Palem]

Thank you, Klaus. The wiki on the Traingular Matrices detailed their storage and did not really go into the iterators behaviors for them, hence the confusion.

I would have expected UpperMatrix< DynamicMatrix<double>>::iterator to be semantically different from DynamicMatrix<double>::iterator.

If one needs all elements to be iterated over one could always use DynamicMatrix<double>::iterator

but when one needs to iterate only over the triangular portion of the matrix (for which exact reason the matrix is wrapped with adapter such as UpperMatrix) it is surprising to see the iterator behaving exactly like that of the underlying matrix.

I guess this falls into the same scenario as that of the triangular views issue that is open. Probably this may be addressed as part of that.

Thank you.

‌