This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen
Bug 649 - colamd always fail when matrix is uncompressed
Summary: colamd always fail when matrix is uncompressed
Status: NEW
Alias: None
Product: Eigen
Classification: Unclassified
Component: Sparse (show other bugs)
Version: 3.2
Hardware: All All
: Normal Unknown
Assignee: Nobody
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-19 13:19 UTC by Pavel
Modified: 2019-12-04 12:35 UTC (History)
1 user (show)



Attachments

Description Pavel 2013-08-19 13:19:17 UTC
In COLAMDOrdering, line #140, colamd always returns "false" (failed) in case if matrix is in uncompressed format:

info = internal::colamd(m, n, Alen, A.data(), p.data(), knobs, stats); 

Reason:

Line #423 of colamd is always true ( need > Alen ). 

"need" is computed based on number of non-zeros taken from outerIndexPtr()[cols()]
"Alen" is computed based on number of non-zeros returned by nonZeros().

As a result, for uncompressed matrices "need" is always greater than "Alen" - which disables ordering method. Can be seen only in "Debug" build, when assert is triggered.
Comment 1 Desire NUENTSA 2013-08-26 09:40:12 UTC
The COLAMD implementation as provided in Eigen_Colamd.h assumes that the matrix is in compressed mode. If your matrix is in uncompressed format, outerIndexPtr() and innerIndexPtr() will return useless data for the algorithm. 
Maybe we should put an assert in that case ?
Comment 2 Pavel 2013-08-31 07:08:56 UTC
I encountered this problem while using SparseQR for uncompressed matrix.
Does this mean that matrix _must_ be in compressed form for decompositions?
It might be a good idea to stress this fact in documentation (in SparseQR, LU). 
It wasn't clear right (at least for me ;)).
Comment 3 Nobody 2019-12-04 12:35:05 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/649.

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