fix: Cholesky::new returns None non-positive-definite complex matrices#1592
fix: Cholesky::new returns None non-positive-definite complex matrices#1592DiogoRibeiro7 wants to merge 5 commits intodimforge:mainfrom
Conversation
* Add known-failing unit test case for SymmetricEigen * Fix eigenvector calculation for subdim=2 case in SymmetricEigen
…rices For complex types, always succeeds (every complex number has a square root), so non-PD matrices were silently producing garbage results. Fix by calling on the real part of each diagonal pivot instead — matching the behaviour already correct for . Fixes dimforge#1536
|
first just to note this has already been fixed in #1574 - but if you're able to answer review comments faster than that I'll probably merge this instead. Secondly before I review, there seems to be some commits that aren't relevant to your PR here - do you mind tidying them up? |
7aed676 to
f2bc954
Compare
Thanks for the suggestion! I went a slightly different route — instead of explicit checks, the closure now just does v.real().try_sqrt().map(T::from_real). This way try_sqrt() on the real part naturally returns None for negative/zero values, and the imaginary part is intentionally ignored to tolerate small floating-point residuals (for Hermitian matrices the diagonal stays real throughout the algorithm). I also cleaned up the unrelated commits. |
…rices For complex types, always succeeds (every complex number has a square root), so non-PD matrices were silently producing garbage results. Fix by calling on the real part of each diagonal pivot instead — matching the behaviour already correct for . Fixes dimforge#1536
f2bc954 to
d136b91
Compare
…7/nalgebra into fix/cholesky-complex-non-pd
For complex types, always succeeds (every complex number has a square root), so non-PD matrices were silently producing garbage results. Fix by calling on the real part of each diagonal pivot instead — matching the behaviour already correct for .
Fixes #1536