new interface for QR decomposition in Matlab 2022a

historically the call to the qr decomposition with only one output argument delivered a matrix that contained the upper triangular factor R in the upper triangular part of the returned matrix and it contained the Householder vectors in the strict lower triangular part. This has obviously changed in the 2022a release of Matalb. Now, it returns only the upper triangular factor R and just zeroes in the lower part. My question is why this has been changed. I can't see any particular benefit to change an interface that has been in use for decades (going back to LinPack). Can anybody explain?

Answer 1

[Christine Tobler]

Yes, we made this change for R2022a. I'm sorry this has caused problems for you, @Klaus Diepold, could you share how you had been using this output?

There were several reasons:

• Not reliable for all cases: The Householder vectors returned by LAPACK have an additional scaling vector tau, which wasn't returned by one-output QR. For the real case, this could usually be reconstructed (although no guarantee for future LAPACK implementations), but for the complex case, I couldn't find any way to reliably reconstruct that scaling vector. This is the reason we have documented this syntax as "call triu to retrieve R" without any description of the lower triangle for a while now.
• Confusing interface: For sparse matrices, we had never returned the Householder vectors as part of the one-output syntax (it wouldn't have been feasible, the datastructure is larger) - so quite some code was calling istriu(qr(A)) in the dense case, and just qr(A) in the sparse case. Most users were just calling the one-output syntax to get the R without the Q, so that was an inconvenient way to do that. In particular, the qr(A, 'econ') case would just return the same as qr(A) in the one-output case, requiring users to both call triu and index, to make the dense case return R just like the sparse case does. For example, here's someone confused about what's going on with this one-output behavior.
• New formats: While *GEQRF always returns the Householder vectors, newer and more efficient LAPACK functions are returning different formats: GEQRT uses compact WY blocks of Householder vectors (requiring some additional storage) and LATSQR is using a series of block QR decompositions resulting in several sets of Householder vectors. Keeping the one-output syntax as always calling GEQRF was restricting our options: Either have the one-output syntax use a slower factorization than the 2-output syntax (when arguably many would call 1-output in hope of a speedup), or restrict the QR function to forever use *GEQRF for all syntaxes.

Answer 2

[John D'Errico]

Yes. You are correct, in that QR now returns only the upper triangular factor.

A = rand(5,3);
result = qr(A)

result = 5×3

-1.4177 -0.6331 -0.5272 0 0.6019 0.4018 0 0 0.5097 0 0 0 0 0 0

In the release history for QR at release R2022a, I see this statement:

The syntax R = qr(A) always returns R as an upper-triangular matrix, regardless of whether A is full or sparse. Previously, for full A, the one-output syntax returned an R matrix with Householder vectors located in the lower-triangular portion of the matrix. These vectors partially defined the Q matrix.

If I had to make a guess, having QR return the extra stuff in the lower part of the matrix confused far more people than it helped. Was anyone using that information from past releases? I don't know, but surely somebody was, as there are a lot of MATLAB users out there. At the same time, anyone who actually wanted that information should be capable of computing it themselves anyway. Such is life. Things change. :)

[Klaus Diepold]

well, the Householder vectors are computed as part of the qr- decomposition, why throw them away?

If I want to have these vectors then I have to compute them myself now, I consider this change wasteful without any particular benefit except for a potential confusion.

This interface existed many decades, without causing problems.

And yes, things are changing, hopefully for the better.