看起来许多项目都需要进行矩阵数学计算，并陷入首先构建某些向量类的陷阱，然后逐步添加功能，直到他们被困在半吊子自定义线性代数库中并依赖它。
我想避免这种情况，同时又不会依赖于某些间接相关的库（例如OpenCV、OpenSceneGraph）。
有哪些常用的矩阵数学/线性代数库？为什么要选择其中一个而不是另一个？有没有建议不使用某些库的原因？我具体在几何/时间*(2,3,4维)*上使用，但将来可能会使用更高维的数据。
我正在寻找以下方面的差异：API、速度、内存使用、广度/完整性、狭窄/特定性、可扩展性和/或成熟度/稳定性。
最终我使用了Eigen3，非常满意。
编辑：
在评论讨论和编辑后，我想提供一些关于特定实现的优缺点以及为什么在特定情况下你可能会选择其中之一的更多信息。
GMTL -
优点：简单的API，专门设计用于图形引擎。包括许多面向渲染的基本类型（如平面、AABB、带有多重插值的四元数等），这些类型在任何其他软件包中都没有。非常低的内存开销，速度相当快，易于使用。
缺点：API非常专注于渲染和图形，不包括通用的（NxM）矩阵、矩阵分解和求解等，因为这些超出了传统图形/几何应用的范畴。
Eigen -
优点：清晰的API，相当易于使用。包括一个几何模块，具有四元数和几何变换。内存开销较小。完整的，高性能的求解大型NxN矩阵和其他通用数学例程。
缺点：可能比你想要的范围更大（？）。与GMTL相比，几何/渲染特定例程较少（即：欧拉角定义等）。
IMSL -
优点：非常完整的数值库。速度非常快（据说是最快的求解器）。迄今为止最大、最完整的数学API。商业支持、成熟、稳定。
缺点：费用高，不便宜。几乎没有几何/渲染特定方法，因此您需要在其线性代数类之上自己编写。
NT2 -
优点：提供更熟悉的语法，如果您习惯MATLAB的话。提供了大型矩阵的完整分解和求解等功能。
缺点：数学方面，不注重渲染。可能不如Eigen性能好。
LAPACK -
优点：非常稳定，经过长时间证明的算法。存在已久。完整的矩阵求解等。许多晦涩的数学选项。
缺点：在某些情况下性能不如其他库。从Fortran移植而来，使用奇怪的API。
对我来说，问题归结为一个问题 - 你计划如何使用它。如果你只关注渲染和图形，我喜欢通用图形工具包，因为它表现良好，并支持许多有用的渲染操作，无需自己实现。如果你需要一般目的的矩阵求解（即：大矩阵的SVD或LU分解），我会选择Eigen，因为它处理这个问题，提供一些几何操作，并且在大矩阵解决方案方面非常高效。您可能需要编写更多自己的图形/几何操作（在它们的矩阵/向量之上），但那并不可怕。
我是一个很挑剔的人，认为如果我要投资于一个代码库中，最好知道自己到底在投资什么。当我在审查这个库时，我认为批判性思维比吹捧更加有利，因为它的问题对未来的影响比好处要多得多。所以我会稍微过度地描述一下，提供一种能够帮助我自己和其他人的回答。请注意，这是基于我进行的少量评论/测试而得出的结论。噢，我从Reed那里偷了一些正面的描述。
我首先要提到的是，尽管GMTL有其独特之处，但由于Eigen2存在不安全性问题，我还是选择了GMTL。但我最近了解到，Eigen2的下一个版本将包含定义文件，可以关闭对齐代码，使其变得安全。所以我可能会转向Eigen2。
更新：我已经转向使用Eigen3。尽管它有些独特之处，但其范围和优雅程度是难以忽视的，而且可以通过定义文件关闭使其不安全的优化。
优点：LGPL MPL2、干净、设计精良的API，相当易于使用。似乎得到了充满活力的社区的精心维护。内存占用低，性能高。是面向普通线性代数的，但也提供了很好的几何功能。全为头文件库，无需链接。
独特之处/缺点：(一些或全部可以通过当前发展分支 Eigen3中可用的定义文件避免)
好处: LGPL协议，API简单易懂，专为图形引擎而设计。包含很多针对渲染优化的原始类型（如平面、AABB、具有多种插值的四元数等），其他软件包中没有这些类型。内存开销非常低，速度相当快，易于使用。全部基于头文件实现，不需要链接。
缺点:
length( Vec( vecA - vecB ) )
length( makeCross( vecA, vecB ) ) gmtl::length( gmtl::makeCross( vecA, vecB ) ) vecA.cross( vecB ).length()无法确定，因为他们似乎对网页的分形图像头部更感兴趣。看起来更像一个学术项目而不是一个严肃的软件项目。
最新版发布已经超过两年了。
显然没有英语文档，尽管据说有一些法语文档在某个地方。
无法找到项目周围的社区痕迹。
优点：老而成熟。
缺点：
就我所知，我尝试过Eigen和Armadillo，下面是简要评估：
Eigen的优点： 1. 完全自包含 - 不依赖于外部的BLAS或LAPACK。 2. 文档不错。 3. 据说很快，尽管我还没有测试过。
缺点： QR算法仅返回一个矩阵，其中R矩阵嵌入在上三角中。不知道其余矩阵来自何处，也无法访问Q矩阵。
Armadillo的优点： 1. 广泛的分解和其他函数（包括QR）。 2. 相当快（使用表达式模板），但我还没有真正将其推向高维度。
缺点： 1. 依赖于外部的BLAS和/或LAPACK进行矩阵分解。 2. 我认为文档不足（包括有关LAPACK的具体信息，除了更改#define语句）。
如果有一个自包含且易于使用的开源库可用，那将是很好的事情。我遇到了这个问题已经10年了，这让人沮丧。曾经，我使用GSL进行C编程，并编写了C++封装器，但使用现代C++ - 尤其是利用表达式模板的优点 - 我们不应该在21世纪还需要使用C。只是我的个人见解。
关于GLM呢？
它基于OpenGL着色器语言(GLSL)规范，并在MIT许可下发布。显然是针对图形编程人员的。
好的，我认为我知道你在寻找什么。从 Reed Copsey 的建议来看，GGT 是一个相当不错的解决方案。
个人而言，我们自己编写了一个小型库，因为我们经常处理有理点——大量有理 NURBS 和 Bezier 曲线。
事实证明，大多数 3D 图形库使用的是投影点进行计算，这些投影点在投影数学中没有任何基础，因为这样可以得到您想要的答案。我们最终使用了 Grassmann 点，它们具有坚实的理论基础并减少了点类型的数量。Grassmann 点基本上是现在人们正在使用的相同计算，具有健全的理论优势。最重要的是，它使我们的思维更加清晰，因此我们出现了更少的错误。Ron Goldman 在计算机图形学中写了一篇关于 Grassmann 点的论文，名为 "On the Algebraic and Geometric Foundations of Computer Graphics"。
虽然这与你的问题没有直接关系，但是是一篇有趣的阅读材料。