在boost中有没有什么有效的方法来动态改变compress_matrix？

Question

我正在使用ublas：：压缩矩阵来使用UMFPACK，这是一个稀疏线性求解器。因为我在做模拟，所以每次线性系统的构造都略有不同，这可能涉及放大/缩小系数矩阵和一些稀疏矩阵乘法。线性系统的规模约为25k。

即使boost有一个用于UMFPACK的绑定补丁，我仍然需要不时地更改矩阵，有时甚至计算出非零值的数量也会很耗时(理想情况下，我必须在初始化矩阵时给出非零值的数量)。另外，我使用ublas::range动态追加列/行。

所以我的问题是:有没有什么有效的方法来做到这一点？现在它对我来说太慢了。转置一个维度为15k的矩阵需要近6秒的时间，添加大约12k行是很快的(因为我猜它是行主矩阵)，但是向矩阵添加相同数量的列可能需要20秒(我猜是出于与上面相同的原因，所以即使我使用列主矩阵，所需的总时间也是相同的)。

有点绝望了。欢迎任何建议。

干杯。

Answer 1

我不熟悉您的包，但是为什么您(理想情况下)必须指定矩阵中非零元素的数量？你不能过多地指定然后缩小大小吗？

我也不明白为什么添加列要花这么多钱。稀疏格式应该能够处理这一点。我会得出结论，有两件事正在发生。要么你的矩阵正在以某种方式被转换成一个非稀疏矩阵，然后再转换回来(看起来很可怕，在任何像样的稀疏矩阵包中都是不可能的)，要么插入的代码是二次的，因为它重复地插入值，每次都会移动到所有其他值上。

后者似乎是有可能的。我会尝试使用我自己的“插入列”代码，该代码获取当前的稀疏矩阵，计算出还有多少个条目，分配一个更大的块，然后按顺序复制，并在执行过程中插入新的列。这是线性的，本质上应该是瞬时的。我不知道这是否足以解决整个问题，但这应该是一个开始。

此外，如果矩阵有大约25k个条目，那么没有合理的答案来解释为什么复制或转置它应该花费超过几毫秒的时间。我认为您需要对这个问题的各个部分进行基准测试，并真正确定时间的去向，除非上面的添加列的解决方案解决了您的问题。

Answer 2

每次你是如何构建矩阵的，你是从某种不同的软件中进行接口的吗？在这种情况下，我想在接口上花费的时间是相当低的。

对于uBlas，您使用-DNDEBUG标志，对吗？

我仍然不确定问题是什么……

最好的，乌穆特

Answer 3

而不是通过连接几组不同的值来构造A，您是否考虑过将它们保存在单独的矩阵中，并使用现有的求解器例程来构造您自己的整体求解器？基本上，您将对一个组件矩阵应用适当的分解(LU、QR等)，在后续组件上运行相应的更新/转换，并对每个后续矩阵重复。然后，您将使用分解后的组件矩阵来计算您的解。但是，不清楚您一直使用的库是否会直接支持这一点，或者您是否必须自己编写一些/所有的数值例程。