2
$\begingroup$

When there are very small differences between entries in a diagonal matrix, sometimes JordanDecomposition does not evaluate and gives an error message:

JordanDecomposition[{{1., 0.}, {0., 1. + 2.*10^(-16)}}]

(* Out: JordanDecomposition[{{1., 0.}, {0., 1.}}] *)

JordanDecomposition::pvec: Unable to find principal vectors for eigenvalue 1.`.

Weirdly, the documentation for this error message says

This message is generated by a failure in the algorithm for computing JordanDecomposition of a symbolic matrix.

although the matrix is clearly numeric. The corresponding symbolic matrix works fine:

JordanDecomposition[{{a, 0}, {0, b}}]

(* Out: {{{1, 0}, {0, 1}}, {{a, 0}, {0, b}}} *)

  1. Is this a bug?

  2. Is there a workaround?

Improve this question
$\endgroup$
14
  • $\begingroup$ It works if you use exact numbers: JordanDecomposition[{{1, 0}, {0, 1 + 2*10^(-16)}}] $\endgroup$
    – Domen
    Commented Sep 7, 2021 at 0:21
  • 2
    $\begingroup$ At machine precision it is not possible to distinguish whether or not 1 is a multiple eigenvalue. It likely gets treated as such ( I cannot check this right now). Then finds only one eigenvector. Ergo the message and unevaluated result. Again, the Jordan decomposition is not well behaved here. The Schur decomposition is numerically sound and often better to use for approximate numeric matrices. $\endgroup$
    – Daniel Lichtblau
    Commented Sep 9, 2021 at 0:07
  • 3
    $\begingroup$ (1) What I am getting at is that the numeric issue means it is likely to be badly behaved. In effect you are asking it to find a nontrivial Jordan block that does not exist. Suppose instead that one did exist but the software insteadtreated two nearly identical (at machine precision) eigenvalue as distinct. You'd get two eigenvectors, one of which was garbage. $\endgroup$
    – Daniel Lichtblau
    Commented Sep 9, 2021 at 3:56
  • 3
    $\begingroup$ (2) I was told to extend JordanDecomposition to handle approximate numeric matrices over 20 years ago. I thought it was a bad idea then, and subsequent usage has only confirmed that. For one, it gives people the idea that this makes sense when really it does not due to structural discontinuities and the numerics that go with them. Case in point being this discussion. $\endgroup$
    – Daniel Lichtblau
    Commented Sep 9, 2021 at 3:58
  • 2
    $\begingroup$ (3) several years ago I adopted the strategy of letting the code fail rather than forcing buggy results (some of which resulted in kernel crashes). I have had no regrets over that decision. $\endgroup$
    – Daniel Lichtblau
    Commented Sep 9, 2021 at 4:01

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.