检查矩阵是否为奇异的快速方法？（不可逆，det = 0）答案

【问题标题】：Fast method to check if a Matrix is singular? (non-invertible, det = 0)检查矩阵是否为奇异的快速方法？（不可逆，det = 0）
【发布时间】：2012-06-05 07:26:09
【问题描述】：

检查一个小方阵（

【问题讨论】：

可能是高斯消元法。
不确定它是否是最快的，但 SVD 会告诉你。如果 SVD 找到的任何奇异值都是 0，那么您的矩阵就是奇异的。
@JustinPeel：LU 分解在行列式方面的表现优于 SVD，但 SVD 为您提供了更多信息：它告诉您“哪些方向”对于矩阵来说是奇异的。无论如何，测试一个矩阵是否在数值上是奇异的最好通过计算（一个界限）它的条件数来执行，而不是通过计算一个行列式（这里的行列式是 16 线性的，所以小误差被提高到 16 次方），所以 SVD 是好的，如果速度不是一个严重的问题。
我认为这是一种常见的 stackoverflow 情况：这里是如何做 X - 这真的是你想要做的吗？为什么要找到行列式/矩阵是否可逆？无论如何，您可能希望 SVD 从矩阵不可逆或几乎不可逆的情况中恢复。

标签： algorithm matrix matrix-inverse

【解决方案1】：

最好的方法是通过 SVD 计算 condition number 并检查它是否大于 1 / epsilon，其中 epsilon 是机器精度。

如果您允许假阴性（即矩阵有缺陷，但您的算法可能无法检测到它），您可以使用 Wikipedia 文章中的 max(a_ii) / min(a_ii) 公式作为条件数的代理，但您必须先计算 QR 分解（该公式适用于三角矩阵）：A = QR 与 R 正交，然后是 cond(A) = cond(Q)。也有一些技术可以通过 O(N) 操作计算 Q 的条件数，但更复杂。

【讨论】：

使用 LAPACK，我们可以将 DGECON/SGECON 用于双精度/单精度通用矩阵或具有可用结构（带状、对称等）矩阵的类似例程之一。这使用 LU 分解

【解决方案2】：

我同意高斯消元法。 http://math.nist.gov/javanumerics/jama/doc/Jama/LUDecomposition.html 记录 LU 分解 - 从矩阵构造 LU 分解后，您可以在其上调用方法来获取行列式。我的猜测是，至少值得将其与任何更专业的方案进行比较。

【讨论】：

LU 分解是计算行列式的标准方法。行列式并不是测试矩阵缺陷的标准方法。

【解决方案3】：

在 R 中，差异很接近，但 qr 分解胜出。请尝试以下操作：

    Sig <- matrix(rnorm(16),4,4)
    
    a <- Sys.time()
    for(j in 1:1000){
      out <- svd(Sig)
      cond <- any(out$d < 1e-10)
    }
    Sys.time()-a
    
    a <- Sys.time()
    for(j in 1:1000){
      out <- qr(Sig)
      cond <- out$rank < NROW(Sig)
    }
    Sys.time()-a

【讨论】：

【解决方案4】：

最快的方法可能是为您希望处理的每个大小矩阵硬编码一个行列式函数。

这里是 N=3 的一些伪代码，但如果您查看 The Leibniz formula 的行列式，则所有 N 的模式都应该是清晰的。

function is_singular3(matrix) {
    det = matrix[1][1]*matrix[2][2]*matrix[3][3]
        - matrix[1][1]*matrix[2][3]*matrix[3][2]
        - matrix[1][2]*matrix[2][1]*matrix[3][3]
        + matrix[1][2]*matrix[2][3]*matrix[3][1]
        + matrix[1][3]*matrix[2][1]*matrix[3][2]
        - matrix[1][3]*matrix[2][2]*matrix[3][1];

     if(det==0) return true
     else return false
}

【讨论】：

从零开始的 epsilon 距离检查是为了浮点矩阵。
他需要一个元程序来生成硬编码公式。
对于 n=16，这可能写起来很麻烦。
-1 对于 n=15，莱布尼茨公式将有 1.3 万亿次加法。这不是一个现实的答案。
-1，问题不在于如何有效地生成代码。问题在于问题的一般时间复杂度。