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?
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.
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.
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.
-- 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.