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

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: <eigen@xxxxxxxxxxxxxxxxxxx>*Subject*: [eigen] SparseMatrix with non POD-"Scalar" type (e.g. SparseBlockMatrix) yields unnecessary initialisations of Scalar-type?*From*: <Daniel.Vollmer@xxxxxx>*Date*: Sat, 16 Mar 2013 18:00:01 +0000*Accept-language*: en-US, de-DE*Thread-index*: AQHOIm9wneRkx0XlXEePt/xGQO/PJg==*Thread-topic*: SparseMatrix with non POD-"Scalar" type (e.g. SparseBlockMatrix) yields unnecessary initialisations of Scalar-type?

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**

**Follow-Ups**:

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] Sparse Vector** - Next by Date:
**[eigen] SparseMatrix with non POD-"Scalar" type (e.g. SparseBlockMatrix) yields unnecessary initialisations of Scalar-type?** - Previous by thread:
**Re: [eigen] Sparse Vector** - Next by thread:
**[eigen] SparseMatrix with non POD-"Scalar" type (e.g. SparseBlockMatrix) yields unnecessary initialisations of Scalar-type?**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |