Eigen 3.3 SVD.solve返回错误的值

时间:2017-11-23 16:46:10

标签: c++ eigen

从Eigen 3.2.7更新到3.3.4后,我遇到了JacobiSVD.solve的一个问题,它返回了一个非常错误的结果。 BDCSVD产生相同的结果。

可以使用以下代码重现该问题:

#include <Eigen/Eigen>
#include <Eigen/SVD>

int main(int argc, const char * argv[]) {

    // M is calculated beforehand and does not change with different Eigen versions
    Eigen::Matrix<double, 12, 12> M = Eigen::Matrix<double, 12, 12>::Zero();
    M(0,0) = 27; M(0,2) = 4.3625039999999995; M(0,3) = -9; M(0,5) = -2.1812519999999997; M(0,6) = -9;
    M(1,1) = 27; M(1,2) = 3.2718720000000001; M(1,4) = -9; M(1,7) = -9; M(1,8) = -1.6359360000000001;
    M(2,0) = 4.3625039999999995; M(2,1) = 3.2718720000000001; M(2,2) = 2.4780489612000003; 
    M(2,3) = -2.1812519999999997; M(2,5) = -0.82601632039999995; M(2,7) = -1.6359360000000001;
    M(2,8) = -0.82601632039999995; M(3,0) = -9; M(3,2) = -2.1812519999999997; M(3,3) = 9;
    M(4,1) = -9; M(4,4) = 9; M(5,0) = -2.1812519999999997; M(5,2) = -0.82601632039999995;
    M(5,5) = 0.82601632039999995; M(6,0) = -9; M(6,6) = 9; M(7,1) = -9; M(7,2) = -1.6359360000000001; 
    M(7,7) = 9; M(8,1) = -1.6359360000000001; M(8,2) = -0.82601632039999995; M(8,8) = 0.82601632039999995;

    Eigen::JacobiSVD<Eigen::MatrixXd> svd(M, Eigen::ComputeFullU);
    Eigen::Matrix<double, 12, 12> ut = svd.matrixU();

    Eigen::Matrix<double, 6, 10> l_6x10;
    Eigen::Matrix<double, 4, 6> dv0;
    Eigen::Matrix<double, 4, 6> dv1;
    Eigen::Matrix<double, 4, 6> dv2;

    for(int i = 0; i < 4; i++) {
        int a = 0, b = 1;

        for(int j = 0; j < 6; j++) {
            dv0(i, j) = ut(3 * a + 0, 11 - i) - ut(3 * b + 0, 11 - i);
            dv1(i, j) = ut(3 * a + 1, 11 - i) - ut(3 * b + 1, 11 - i);
            dv2(i, j) = ut(3 * a + 2, 11 - i) - ut(3 * b + 2, 11 - i);

            b++;
            if (b > 3) {
                a++;
                b = a + 1;
            }
        }
    }

    for(int i = 0; i < 6; i++) {
        l_6x10(i,0) =       (dv0(0, i) * dv0(0, i) + dv1(0, i) * dv1(0, i) + dv2(0, i) * dv2(0, i));
        l_6x10(i,1) = 2.0f * (dv0(0, i) * dv0(1, i) + dv1(0, i) * dv1(1, i) + dv2(0, i) * dv2(1, i));
        l_6x10(i,2) =       (dv0(1, i) * dv0(1, i) + dv1(1, i) * dv1(1, i) + dv2(1, i) * dv2(1, i));
        l_6x10(i,3) = 2.0f * (dv0(0, i) * dv0(2, i) + dv1(0, i) * dv1(2, i) + dv2(0, i) * dv2(2, i));
        l_6x10(i,4) = 2.0f * (dv0(1, i) * dv0(2, i) + dv1(1, i) * dv1(2, i) + dv2(1, i) * dv2(2, i));
        l_6x10(i,5) =       (dv0(2, i) * dv0(2, i) + dv1(2, i) * dv1(2, i) + dv2(2, i) * dv2(2, i));
        l_6x10(i,6) = 2.0f * (dv0(0, i) * dv0(3, i) + dv1(0, i) * dv1(3, i) + dv2(0, i) * dv2(3, i));
        l_6x10(i,7) = 2.0f * (dv0(1, i) * dv0(3, i) + dv1(1, i) * dv1(3, i) + dv2(1, i) * dv2(3, i));
        l_6x10(i,8) = 2.0f * (dv0(2, i) * dv0(3, i) + dv1(2, i) * dv1(3, i) + dv2(2, i) * dv2(3, i));
        l_6x10(i,9) =       (dv0(3, i) * dv0(3, i) + dv1(3, i) * dv1(3, i) + dv2(3, i) * dv2(3, i));
    }

    Eigen::Matrix<double, 6, 4> L_6x4;

    for(int i = 0; i < 6; i++) {
        L_6x4(i, 0) = l_6x10(i, 0);
        L_6x4(i, 1) = l_6x10(i, 1);
        L_6x4(i, 2) = l_6x10(i, 3);
        L_6x4(i, 3) = l_6x10(i, 6);
    }

    // L_6x4 has the following values on 3.2.7 (everything else is 0):
    //
    // L_6x4(0,2) = 1;
    // L_6x4(1,0) = 1;
    // L_6x4(1,1) = 1;
    // L_6x4(5,0) = -1.137432760287006;
    // L_6x4(5,2) = -1.1374327602870071;
    // L_6x4(5,3) = -1.1374327602870049;
    //
    //
    // on 3.3.4 it has the following slightly different values:
    //
    // L_6x4(0,2) = 1;
    // L_6x4(1,0) = 1;
    // L_6x4(1,1) = 1;
    // L_6x4(5,0) = -1.1374327602869998;
    // L_6x4(5,2) = -1.1374327602870271;
    // L_6x4(5,3) = -1.1374327602869889;

    // Rho is calculated beforehand and does not change with different Eigen versions
    Eigen::Matrix<double, 6, 1> Rho;
    Rho << 0.25, 0.140625, 0, 0.390625, 0.25, 0.140625;

    Eigen::JacobiSVD<Eigen::MatrixXd> l_6x4(L_6x4, Eigen::ComputeFullU | Eigen::ComputeFullV);
    Eigen::Vector4d B4 = l_6x4.solve(Rho);

    // The slight difference in L_6x4 apparently causes an insane difference in the result of solve.
    //
    // Eigen 3.2.7: B4={0.056766494562302421, 0, 0, -0.064568070601816963}
    // Eigen 3.3.4: B4={-4773392957911.6992, 0, 0, -4196637484493.9165}
    return 0;
}

使用Eigen 3.3.4计算的B4的值让我认为这可能是一些奇怪的内存对齐问题,SDK中的错误或希望这个程序中的错误。

我尝试使用-DEIGEN_DONT_ALIGN_STATICALLY或-DEIGEN_DONT_VECTORIZE和-DEIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT进行编译。 我也在这些矩阵上尝试了Eigen :: DontAlign。 这些都不会对结果产生任何影响。

使用ndk-r14b clang c ++ _ static在Android(4.4和5.1)上测试 和Mac(macOs Sierra 10.12.6):“clang ++ -std = c ++ 14 -g -O0 -I / EIGEN_PATH main.cpp -o main”

1 个答案:

答案 0 :(得分:3)

这两个答案实际上非常相似,产生类似的残差。这是因为你的矩阵有两个零奇异值,第三个矩阵非常接近机器精度。因此,根据舍入误差,它被认为是0,在这种情况下,您可以在解决方案的剩余3D子空间内获得最小范数解决方案:

{0.056766494562302421, 0, 0, -0.064568070601816963}

和0.91的残差。否则它被认为是有意义的,然后你在较小的2D子空间内得到最小范数解(对应于两个零奇异值):

{-4773392957911.6992, 0, 0, -4196637484493.9165}

残差较小,为0.89。因此,第二种解决方案在某种意义上更准确,但如果您更喜欢具有较小范数但残差较高的解,那么您可以调整阈值,使第三个奇异值被认为是零。这是通过setThreshold完成的:

Eigen::JacobiSVD<Eigen::MatrixXd> l_6x4;
l_6x4.setThreshold(1e-14);
l_6x4.compute(L_6x4, Eigen::ComputeFullU | Eigen::ComputeFullV);
Eigen::Vector4d B4 = l_6x4.solve(Rho);