我不确定这个问题有一个正确答案，但我们走了。虽然可以用线性代数形式陈述许多数值问题，但从我有限的经验来看，使用Math.NET而不是在原始数组上编写等效操作的简单操作存在性能开销。
作为测试用例，我编写了代码来计算向量与列表中最接近的向量之间的距离，有3个版本：在数组上运行，在密集向量上运行，以及使用MKL提供程序在密集向量上运行。在数组上运行比在向量上运行快4倍，比使用MKL提供程序快3倍。
缺点是我必须手动编写距离计算，而不是利用内置的Norm函数。好处是它更快。 注意：我没有发布代码，如果需要，我会很乐意这样做，我可能也会不正确地使用Math.NET。
所以我的问题如下：在我看来，使用更高级别的抽象会带来性能成本。这是一般的情况，还是有情况（如实例的稀疏矩阵），使用Math.NET预期会超过阵列上的手动编写操作？
如果是这种情况，我倾向于认为使用Math.NET的线性代数部分对于涉及矩阵的“真实”代数非常有用，以避免重新实现更复杂的计算/算法，并且可能对于代码可读性，但是对于通过向量操作更简单的向量的操作，处理原始数组可能是更好的主意。
任何关于何时使用图书馆以及何时应该推出自己的图书馆的任何启示都将不胜感激！
答案 0 :(得分：24)
免责声明：我正在维护Math.NET Numerics。
Math.NET Numerics试图提供的工具包的主要价值是开发人员的工作效率，特别是那些没有博士学位的人会遇到困难或浪费大量时间来实现这些有时相当复杂的算法本身，可能很糟糕 - 而不是花时间在他们的实际问题上。
然后，您之前可能已经使用过您需要的功能。他们中的一些人可能已经发现并指出了一些问题，并回馈了他们的改进。 更多用户有助于提高代码质量和稳定性。不幸的是，这也给我们带来了一个主要的缺点： 它还会使代码更加通用，这通常会使其效率低于高度专业化的实现，从而完全满足您的需求。
这就像Cody Gray的评论一样：如果它工作且足够快就使用它，否则要么帮助修复它并让它工作（和快速），选择另一个有效的工具包，或者实现你需要的东西你自己。幸运的是，Math.NET Numerics还有更多选项，见下文。
因此，我同意你的结论：如果你实际上不需要任何复杂的操作，不要使用非常大的数据，但性能很重要，直接使用数组或其他数据结构没有任何问题（特别是F＃我个人认为原始数据结构比C＃更频繁。当然，这是以失去一些便利为代价的风险，以及当您开始需要更多操作后，最终可能最终重新实现工具包的风险。最后，它还取决于这对您的项目有多重要，以及您是否可以花费资源和时间来维护自己的数学代码。
然而，根据我自己的经验，拥有代码通常是一个优势（因此您可以进行更改，立即生效）并使其简单集中（因此它完全符合您的需要）只做那个。）