似乎许多项目慢慢地发现需要做矩阵数学，并陷入了首先构建一些向量类，然后慢慢添加功能的陷阱，直到他们被发现构建了一个半成品的自定义线性代数库，并依赖于它。
我想避免这种情况，同时不依赖于一些切线相关的库(例如OpenCV, OpenSceneGraph)。
有哪些常用的矩阵数学/线性代数库，为什么决定使用一个而不是另一个?有没有因为某些原因而被建议不要使用的?我特别在几何/时间上下文中使用这个*(2,3,4 Dim)*，但将来可能会使用更高维度的数据。
我正在寻找关于以下任何方面的差异:API、速度、内存使用、广度/完整性、狭窄性/特异性、可扩展性和/或成熟度/稳定性。
更新
我最终使用了我非常满意的Eigen3。
当前回答
我发现这个库非常简单和实用(http://kirillsprograms.com/top_Vectors.php)。这些是通过c++模板实现的基本向量。没有花哨的东西-只是你需要做的向量(加，减，乘，点，等等)。
其他回答
弗伦斯
http://flens.sf.net
它还实现了许多LAPACK函数。
我是这个主题的新手，所以我不能说太多，但BLAS在科学计算中几乎是标准的。BLAS实际上是一个API标准，它有许多实现。老实说，我不确定哪种实现最受欢迎，或者为什么最受欢迎。
如果你还想做常见的线性代数运算(求解系统、最小二乘回归、分解等)，请参考LAPACK。
不管怎样，艾根和犰狳我都试过了。下面是一个简短的评价。
特征 优点: 1. 完全独立-不依赖于外部BLAS或LAPACK。 2. 良好的文档。 3.据说很快，不过我还没测试过。
劣势: QR算法只返回一个矩阵，R矩阵嵌入在上面的三角形中。不知道矩阵的其余部分从何而来，也不知道Q矩阵可以被访问。
犰狳 优点: 1. 广泛的分解和其他功能(包括QR)。 2. 相当快(使用表达式模板)，但同样，我没有真正将它推到高维。
缺点: 1. 依赖于外部BLAS和/或LAPACK进行矩阵分解。 2. 恕我直言，缺少文档(包括wrt LAPACK的细节，除了更改#define语句)。
如果有一个开放源码库，它是自包含的，并且易于使用，那就太好了。我已经遇到同样的问题10年了，这很令人沮丧。有一次，我使用GSL来编写C语言，并围绕它编写c++包装器，但是使用现代c++——特别是使用表达式模板的优点——我们不应该在21世纪搞乱C语言。只有我的两便士。
好吧，我知道你在找什么了。正如Reed Copsey所建议的，GGT似乎是一个相当好的解决方案。
就我个人而言，我们有自己的小库，因为我们经常处理有理点——很多有理点NURBS和bezier。
It turns out that most 3D graphics libraries do computations with projective points that have no basis in projective math, because that's what gets you the answer you want. We ended up using Grassmann points, which have a solid theoretical underpinning and decreased the number of point types. Grassmann points are basically the same computations people are using now, with the benefit of a robust theory. Most importantly, it makes things clearer in our minds, so we have fewer bugs. Ron Goldman wrote a paper on Grassmann points in computer graphics called "On the Algebraic and Geometric Foundations of Computer Graphics".
和你的问题没有直接关系，但是很有趣。
我把很多代码(3D几何、线性代数和微分方程)从不同的库移植到Eigen中——几乎在所有情况下都提高了性能和代码的可读性。
一个没有提到的优点是:SSE与Eigen一起使用非常容易，这极大地提高了2D-3D操作的性能(其中所有内容都可以填充到128位)。
