这个问题好像之前有提到过：
https ://forum.linuxcnc.org/forum/30-cnc-machines/26392-the-study-of-arithmetic

如果这真的是错误的，我们会在哪里看到问题？

根据我将相关函数的主体更改为 pmMatRpyConvert abort()。测试套件的结果：

运行测试：202 次测试运行，202 次成功，0 次失败 + 0 次预期

换句话说，我们的正常测试甚至不会调用这个函数。

不过，似乎 pumakins 间接使用了该功能。pumakins 没有测试。

我有一种感觉，pumakins 也经常被报道为片状。

pumakins 不仅仅是 genserkins 的通用版本吗？

我不是特别擅长跟踪包含，但在我看来 genserkins 根本不使用 posemath。

gomath 在相同的条件下使用 GO_PI_2，但它被定义为 PI/2

所以至少其中一个可能是错误的。
（并且已经持续了大约 10 年）

也许2可以合并在一起？或被依赖取代？http://glm.g-truc.net/0.9.8/api/modules.html

不，我们不能在这里依赖 glm 这样的 C++ 库，因为这段代码需要编译才能在 Linux 内核空间中运行（对于某些用户和配置），如果没有不可维护的技巧，我们就不能用 C++ 代码做到这一点。

是的，posemath 和 gomath 的重复是不幸的，更何况因为两者起源于不同时期的 NIST；LinuxCNC 本身的祖先起源于 NIST 作为 EMC，并且一直使用 posemath。后来在添加 genserkins 时添加了 gomath。posemath 和 gomath 似乎都没有真正得到维护。我检查了最新的 NIST posemath 版本，它与 LinuxCNC 今天为 pmMatRpyConvert 所做的代码完全相同。 https://github.com/usnistgov/rcslib/blob/master/src/posemath/_posemath.c似乎是基于 github 用户名的官方镜像。

为什么它需要在内核空间中运行？一切都可以在 rt preempt 的用户空间中运行。

因为我们在使用内核模块的模式下支持 RTAI。是的，如果有一天我们放弃这种模式，那么我们可以在实时组件中重新审视有关 C++ 的决定。

也许 genserkins 需要测试，如果它随着变化的表现不同会很有趣。

有什么可以与 RTAI 一起使用，但不能与 rt preempt 一起使用的东西吗？以我的经验，rtai 对于较新的内核和 64 位来说很麻烦。

[这里不是对 RTAI 进行全民投票的地方]

@lethang12cdt
在 pmRpyMatConvert 之后使用 pmMatRpyConvert 应该会生成原始向量。如果不是，请进行建议的更改并再次测试。

实际上看来我错了，上游有与此错误提议相同的修复。我没有阅读源代码。（只是复制上游的副本失败了，因为他们在过去一百年里不兼容地改变了他们的 API）

我仍然希望我们有一个测试。