问被qr.q()迷惑了:什么是“紧凑”形式的正交矩阵？

EN

我已经根据OP的要求研究了同样的问题，但我认为这是不可能的。基本上，OP问题是具有显式计算的Q，是否可以恢复H1 H2 ...太好了。我认为如果不从头开始计算QR，这是不可能的，但我也非常有兴趣知道是否有这样的解决方案。

我有一个与OP类似的问题，但在不同的上下文中，我的迭代算法需要通过添加列和/或行来改变矩阵A。第一次，使用DGEQRF计算QR，因此使用紧凑的LAPACK格式。在矩阵A发生变化后，例如，使用新的行，我可以快速构建一组新的反射器或旋转器，这些反射器或旋转器将消除现有R的最低对角线的非零元素，并构建新的R，但现在我有一组H1_old H2_old ...Hn_old和H1_new H2_new ...Hn_new (和类似的tau)，不能混合到单个QR紧凑表示中。我有两种可能性，可能OP也有同样的两种可能性：

1. 总是保持Q和R的显式分离，无论是在第一次计算时，还是在每次更新之后，以额外的flops为代价，但保持所需内存的良好限制。
2. 坚持紧凑的LAPACK格式，但是每次有新的更新进入时，都要保留所有这些更新反射器的迷你集合的列表。在求解系统时，人们会做一个很大的Q'*c，即H1_u3*H2_u3*...*Hn_u3*H1_u2*H2_u2*...*Hn_u2*H1_u1*H2_u1...*Hn_u1*H1*H2*...*Hn*c，其中ui是QR更新号，这可能需要进行大量的乘法运算和跟踪内存，但这绝对是最快的方法。

David的长答案基本上解释了什么是紧凑的QR格式，但没有解释如何获得这种紧凑的QR格式，并将显式计算的Q和R作为输入。