This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen

Bug 1463

Summary: SparseQR not copyable anymore
Product: Eigen Reporter: Jan Rüegg <jan>
Component: SparseAssignee: Nobody <eigen.nobody>
Status: NEW ---    
Severity: API Change CC: chtz, gael.guennebaud, jan
Priority: Normal    
Version: 3.3 (current stable)   
Hardware: All   
OS: All   
Whiteboard:

Description Jan Rüegg 2017-08-24 09:38:19 UTC 
This commit:
https://bitbucket.org/eigen/eigen/commits/404375f0572eda41ab9a80644f1785663c7b154c

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 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/1463.