This bugzilla service is closed. All entries have been migrated to
Bug 1463 - SparseQR not copyable anymore
Summary: SparseQR not copyable anymore
Status: NEW
Alias: None
Product: Eigen
Classification: Unclassified
Component: Sparse (show other bugs)
Version: 3.3 (current stable)
Hardware: All All
: Normal API Change
Assignee: Nobody
Depends on:
Reported: 2017-08-24 09:38 UTC by Jan Rüegg
Modified: 2019-12-04 17:10 UTC (History)
3 users (show)


Description Jan Rüegg 2017-08-24 09:38:19 UTC
This commit:

Added the "noncopyable" attribute to SparseQR. This breaks our code, since it makes it impossible to copy the SparseQR matrices (what we are doing right now).

A workaround would be to do an expensive recalculation ("compute" function) instead of a simple copy, but this is clearly bad for performance.

Is the noncopyable really required?
Comment 1 Gael Guennebaud 2017-08-24 09:49:41 UTC
Why do you need to copy it? A SparseQR object is usually heavy in memory, so instead of copying you should rather share the object.
Comment 2 Jan Rüegg 2017-08-24 10:34:42 UTC
I think the problem is that some of the state of one of the SparseQR objects changes after the copy, while the other remains the same, so really two distinct copies are necessary.

Also, depending on the use case, copying could be useful in a multi-threaded environment, to avoid locking the SparseQR object when its used from multiple threads at the same time.
Comment 3 Gael Guennebaud 2017-09-03 07:28:46 UTC
The only state you can change is through "setPivotThreshold" and you need to call compute() or factorize() so that its effect takes place. So there is no gain in copying SparseQR objects.

Regarding multi-threading, you need to lock only if changing its state, so only if you re-perform the factorization. In this case you clearly need different SparseQR object and again there is no gain in copying SparseQR objects.
Comment 4 Nobody 2019-12-04 17:10:29 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to'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:

Note You need to log in before you can comment on or make changes to this bug.