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