Created attachment 864 [details] minimal test case While running sparseqr_1 I stumbled across a (literally) one in a million bug. This input matrix: [ 10.875, 0, 0, 0, 0; -0.397597, 12.1403, 0, 0, 0.0317254; -0.851737, -0.0269339, 11.3113, 0.0130592, 0; -0.676106, 0, 0.138752, 8.57745, 0] when factored and solved for: [ 10.3612; -2.27836; -10.3179; -7.49344] produces dramatically different results between dense and sparse implementations.
I modified the bug title to more accurately express the problem, which is that the solve result from sparse QR cannot be used to recover the original RHS, i.e. x = A\b A*x is nowhere close to "b" Dense QR and SuiteSparseQR produce different solutions as well but they can successfully recover "b".
Created attachment 865 [details] Improved test case
I did some additional investigation. The problem appears to originate in the COLAMD code. If I override the column permutation with either 1) the order from dense QR or 2) the order from SuiteSparse, I can produce the result each of them calculated, both of which can correctly recover b.
-- 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/1563.