[eigen] SparseMatrix with non POD-"Scalar" type (e.g. SparseBlockMatrix) yields unnecessary initialisations of Scalar-type?

[<Daniel.Vollmer@xxxxxx>]

Hello all,

I've been experimenting with Eigen (3.2.0-beta1 at the moment, but I don't think I'm using any of the new features)
to see whether I can use its SparseMatrix type to store block-matrices of fixed size (instead of scalars).

I've attached my experiment that essentially uses a dense 5x5 matrix as the "Scalar" type. Basically, this works (which is already pretty nice) but I have noticed two things which seem sub-optimal, and so I was curious whether I'm missing something or doing it wrong.

1) The Scalar-type used in SparseMatrix seems to need an abs() function in order to (I assume) only iterate over non-zero elements (AmbiVector.h:308 & 335). Oddly enough, my abs-version was needed to compile, but never got called.
It might be advantageous to provide an iterator that iterates over all elements without making such a guarantee, but then the point shouldn't matter once it is compressed.
2) Many times the single-argument constructor is called for the Scalar-type of SparseMatrix in instances where I don't think this is necessary. As this becomes more and more expensive with a more heavy-weight Scalar type, I'd like to avoid this where possible, for example
- SparseMatrix.h:1108 (insertUncompressed): Element is initialised to 0 even though it is later overwritten by the inserted value. Worked fine for me if I removed the = 0.
- SparseMatrix.h:382 (insertBackByOuterInner) and SparseMatrix.h:392 (insertBackByOuterInnerUnordered): Element is initialised to 0 even though it is later overwritten by the inserted value. I hacked this by making a variant of CompressedStorage::append() that only takes an Index and not a value-ref and calling that instead (because again, the value is later overwritten via the reference we return)
- AmbiVector.h:31 (constructor): This seems fair enough (needed for m_zero)..
- AmbiVector.h:171 (setZero): Shouldn't / couldn't this use assignment from m_zero instead?
- AmbiVector.h:197/206/239 (coeffRef): I don't quite understand this, but I'm not sure the element needs to be initialised here either.

To verify the above, just comment the relevant constructor in the sample code (lines 30-35).

Is this approach (using a custom scalar type) still the recommended way to create sparse block-matrices? Can we reduce the overhead of these initialisations or make them optional?

I'd welcome any feedback. :)

Thanks!
    Daniel Vollmer

--------------------------
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
German Aerospace Center
Institute of Aerodynamics and Flow Technology | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Attachment: main.cpp
Description: main.cpp