首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >被qr.q()迷惑了:什么是“紧凑”形式的正交矩阵?

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

Stack Overflow用户
提问于 2010-06-13 13:37:53
回答 1查看 4.3K关注 0票数 18

R有一个qr()函数,它使用LINPACK或LAPACK执行QR分解(根据我的经验,后者快5% )。返回的主要对象是一个包含在上三角矩阵R中的矩阵"qr“(即R=qr[upper.tri(qr)])。到目前一切尚好。qr的下三角部分包含“紧凑形式”的Q。可以使用qr.Q()从qr分解中提取Q。我想找出qr.Q()的倒数。换句话说,我确实有Q和R,并想把它们放在一个"qr“对象中。R是微不足道的,但Q不是。我们的目标是应用qr.solve(),这比大型系统上的solve()快得多。

EN

回答 1

Stack Overflow用户

发布于 2012-03-27 22:06:09

我已经根据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作为输入。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/3031215

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档