矩阵的逆不准确
Inverse of matrix inaccurate
我正在尝试编写测试来验证矩阵的逆，但是当我使用 FLT_EPSILON 比较结果时测试失败。
比较函数如下所示：test_assert_mat4_eq
我想做的是：
A = random matrix (4x4 float matrix)
B = inv(A)
C = inv(B)
assert(A == C) <---- fails
首先让我解释一下我是如何计算矩阵逆的； mat4 是 4x4 浮点矩阵，如果启用 SIMD，则矩阵的逆将通过 SIMD 指令（SSE2 和 AVX）计算。
您可以在 glm_mat4_inv if SSE2 is enabled then the inverse is calculated via glm_mat4_inv_sse2 also there is glm_mat4_inv_precise_sse2 版本中查看矩阵逆码，通过避免 _mm_rcp_ps 指令来获得更高的精度。我用第二个（glm_mat4_inv_precise_sse2）版本来测试。
assert_true(fabsf(m1[i][j] - m2[i][j]) <= 0.0001);
在我的 macbook 上通过，但在 linux 上仍然失败。
assert_true(fabsf(m1[i][j] - m2[i][j]) <= FLT_EPSILON); 这甚至不会通过 macos。也许与 0.001 比较也适用于 linux 但精度太低。
我还在 glm repo (https://github.com/g-truc/glm/issues/700) 上创建了一个问题，因为这个问题对 glm 也有效。
这有什么问题吗？为什么精度太低？这个可以吗？我应该这样离开吗（通过删除测试或更改精度）？
注意：使用test_rand_mat4函数生成随机矩阵。但我只是用它来生成矩阵。我没有在任何地方使用任何随机矩阵，所有矩阵都是仿射变换矩阵，也许我应该使用仿射变换（这是主要目的）进行比较
一个 4⨉4 矩阵足够小，您可以检测代码以在每一步计算后打印涉及的每个浮点数，然后将 macOS 和 Linux 结果进行比较看看他们的不同之处。 （使用 C 的 printf 中的 %a 格式来打印十六进制浮点数或使用类似 %.30g 的格式来打印十进制的整个值。）
告诉我们差异超过 .0001 是没有意义的，因为我们不知道您的数据有多大。通常，数值误差与所涉及的某些数字的大小大致成正比。
如果在 macOS 和 Linux 运行 使用 IEEE-754 浮点的硬件上执行“相同”操作，则应该获得相同的结果。所以任何差异都可能是因为您没有使用相同的操作。造成这种差异的原因可能包括两个系统使用不同的源代码（例如，因为一个使用 SIMD 因为启用了 SSE，而另一个使用标量代码）或者编译器编译代码的方式不同。暂时覆盖 SSE 决定，以便您在两个系统上测试相同的源代码。调试完成后，如果可能，请在两个系统上测试 SSE 代码。之后，比较SSE代码和非SSE代码。
您不应使用随机数据进行测试，而应从简单的测试用例开始，然后逐步处理更复杂的测试用例。从单位矩阵开始。简单的案例将有助于调试基本逻辑，而不会涉及重大的浮点错误。然后修改元素以生成更复杂的案例。生成测试矩阵时，避免ill-conditioned matrices。我在生成用于测试矩阵求逆的矩阵方面没有经验，因此您将不得不研究如何修改矩阵以改进其条件数，或者其他人可能会提出一些建议。
不要通过调用 inv 两次来测试矩阵求逆。这会遗漏一些简单的错误，例如导致名为 inv 的例程实际上是矩阵复制或取反的复制粘贴错误。相反，使用矩阵逆的已知良好参考实现或使用已知测试用例（单位矩阵的逆是单位矩阵，其他可以构造）或使用逆的其他性质（将逆乘以原始矩阵应该产生单位矩阵）。使用 double 作为测试代码。在 4⨉4 矩阵求逆中发现错误所需的测试用例数量不足以影响性能。
我仔细检查了测试代码，测试代码中存在复制粘贴错误。 _mm_rcp_ps指令用于矩阵求逆函数，提高性能。问题是我在 _mm_rcp_ps 版本和非 _mm_rcp_ps[=26 版本的测试中期望相同的 precision =] 版本。我已经修复了测试。
现在 assert_true(fabsf(m1[i][j] - m2[i][j]) <= 0.0000009f); 在 macOS 上都通过了 Linux precise/accurate 版本
和 assert_true(fabsf(m1[i][j] - m2[i][j]) <= 0.0009f) 都在 macOS 上通过，Linux 用于快速 (_mm_rcp_ps) 版本。
同样的测试也通过了 travis-ci。
另一方面，它不起作用，因为我使用了完全随机的矩阵，甚至随机尺度也不起作用，因为它是病态矩阵（感谢@Eric Postpischil 和@geza）
我正在尝试编写测试来验证矩阵的逆，但是当我使用 FLT_EPSILON 比较结果时测试失败。
比较函数如下所示：test_assert_mat4_eq
我想做的是：
A = random matrix (4x4 float matrix)
B = inv(A)
C = inv(B)
assert(A == C) <---- fails
首先让我解释一下我是如何计算矩阵逆的； mat4 是 4x4 浮点矩阵，如果启用 SIMD，则矩阵的逆将通过 SIMD 指令（SSE2 和 AVX）计算。
您可以在 glm_mat4_inv if SSE2 is enabled then the inverse is calculated via glm_mat4_inv_sse2 also there is glm_mat4_inv_precise_sse2 版本中查看矩阵逆码，通过避免 _mm_rcp_ps 指令来获得更高的精度。我用第二个（glm_mat4_inv_precise_sse2）版本来测试。
assert_true(fabsf(m1[i][j] - m2[i][j]) <= 0.0001);
在我的 macbook 上通过，但在 linux 上仍然失败。
assert_true(fabsf(m1[i][j] - m2[i][j]) <= FLT_EPSILON); 这甚至不会通过 macos。也许与 0.001 比较也适用于 linux 但精度太低。
我还在 glm repo (https://github.com/g-truc/glm/issues/700) 上创建了一个问题，因为这个问题对 glm 也有效。
这有什么问题吗？为什么精度太低？这个可以吗？我应该这样离开吗（通过删除测试或更改精度）？
注意：使用test_rand_mat4函数生成随机矩阵。但我只是用它来生成矩阵。我没有在任何地方使用任何随机矩阵，所有矩阵都是仿射变换矩阵，也许我应该使用仿射变换（这是主要目的）进行比较
一个 4⨉4 矩阵足够小，您可以检测代码以在每一步计算后打印涉及的每个浮点数，然后将 macOS 和 Linux 结果进行比较看看他们的不同之处。 （使用 C 的
printf中的%a格式来打印十六进制浮点数或使用类似%.30g的格式来打印十进制的整个值。）告诉我们差异超过 .0001 是没有意义的，因为我们不知道您的数据有多大。通常，数值误差与所涉及的某些数字的大小大致成正比。
如果在 macOS 和 Linux 运行 使用 IEEE-754 浮点的硬件上执行“相同”操作，则应该获得相同的结果。所以任何差异都可能是因为您没有使用相同的操作。造成这种差异的原因可能包括两个系统使用不同的源代码（例如，因为一个使用 SIMD 因为启用了 SSE，而另一个使用标量代码）或者编译器编译代码的方式不同。暂时覆盖 SSE 决定，以便您在两个系统上测试相同的源代码。调试完成后，如果可能，请在两个系统上测试 SSE 代码。之后，比较SSE代码和非SSE代码。
您不应使用随机数据进行测试，而应从简单的测试用例开始，然后逐步处理更复杂的测试用例。从单位矩阵开始。简单的案例将有助于调试基本逻辑，而不会涉及重大的浮点错误。然后修改元素以生成更复杂的案例。生成测试矩阵时，避免ill-conditioned matrices。我在生成用于测试矩阵求逆的矩阵方面没有经验，因此您将不得不研究如何修改矩阵以改进其条件数，或者其他人可能会提出一些建议。
不要通过调用
inv两次来测试矩阵求逆。这会遗漏一些简单的错误，例如导致名为inv的例程实际上是矩阵复制或取反的复制粘贴错误。相反，使用矩阵逆的已知良好参考实现或使用已知测试用例（单位矩阵的逆是单位矩阵，其他可以构造）或使用逆的其他性质（将逆乘以原始矩阵应该产生单位矩阵）。使用double作为测试代码。在 4⨉4 矩阵求逆中发现错误所需的测试用例数量不足以影响性能。
我仔细检查了测试代码，测试代码中存在复制粘贴错误。 _mm_rcp_ps指令用于矩阵求逆函数，提高性能。问题是我在 _mm_rcp_ps 版本和非 _mm_rcp_ps[=26 版本的测试中期望相同的 precision =] 版本。我已经修复了测试。
现在 assert_true(fabsf(m1[i][j] - m2[i][j]) <= 0.0000009f); 在 macOS 上都通过了 Linux precise/accurate 版本
和 assert_true(fabsf(m1[i][j] - m2[i][j]) <= 0.0009f) 都在 macOS 上通过，Linux 用于快速 (_mm_rcp_ps) 版本。
同样的测试也通过了 travis-ci。
另一方面，它不起作用，因为我使用了完全随机的矩阵，甚至随机尺度也不起作用，因为它是病态矩阵（感谢@Eric Postpischil 和@geza）