The inner indices in the matrix returned by SparseQR::matrixR are unsorted. This makes any componentwise binary operation (e.g. +) fail as it iterates over the indices. This appears to be trivially reproducible: construct a sparse matrix; calculate it's QR; look at the inner indices. If it's not, I'm happy to put together an example.
I made it clear in the doc: https://bitbucket.org/eigen/eigen/commits/314d8cb79f86/ Summary: Bug 694: document that SparseQR::matrixR is not sorted. Now, we need a proper fix to handle unordered sparse matrices. To this end, we need: 1 - a way to tell Eigen that a matrix has unordered entries: runtime flag (like the compressed state), or compile-time via the Option template parameter of SparseMatrix, or even via a decorator 2 - an easy and efficient way to a turn an unordered matrix into an ordered one: in-place sort, or via two transpositions. 3 - decide whether this conversion should be implicitly done on demand, e.g.: when evaluating A+B, if B is unordered, copy it to an ordered one. Questions (1) and (3) are kind of related. For instance, if we go for a compile-time flag for (1), then it would be possible and ok to trigger a static assertion for (3), similar to the case of storage-order mismatch. On the other hand, if we go with with a runtime flag for (1), then we should probably go with implicit conversion for (3), similar to what we do regarding the compressed flag (some matrix decompositions require compressed entries). Indeed, a runtime assertion would not be welcome because a might easily missed that a matrix is unordered if not warned at compile-time. We should come up with a solution for 3.4.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/694.