typo or stale info in qr man

Wojciech Musial (Voitek) <wojciech.musial at gmail.com>
   on Mon, 24 Oct 2016 15:07:55 -0700 writes:

man for `qr` says that the function uses LINPACK's DQRDC, while it in
fact uses DQRDC2.

which is a modification of LINPACK's DQRDC.

But you are right, and I have added to the help file (and a tiny
bit to the comments in the Fortran source).

When this change was done > 20 years ago, it was still hoped 
that the numerical linear algebra community or more specifically
those behind LAPACK would eventually provide this functionality
with LAPACK (and we would then use that),
but that has never happened according to my knowledge.

I had some thoughts on this recently and resolved that the base issue is that R wants successive (Gram/Schmidt-type) orthogonalization of the design matrix, not really QR as such. 

The LINPACK QR routine happens to work by orthogonalization, but it is far from the only way of doing QR, and most likely not the "best" one (speedwise/precisionwise) if a QR decompositiion as such is the target. (Pivoting is only part of the story)

lm() and associates (notably anova()) relies so much on successive terms being orthogonalized that method="qr" really is a misnomer. For much the same reason, it really is too much to expect that numerical analysts would enforce orthogonality features on a general QR-decomposer. 

I suppose that if we want to be free of LINPACK, we may need to step back and write our own orthogonalization routines based on other routines in LAPACK or on the BLAS directly.

-pd

Thank you for the 'heads up'.

Martin Maechler
ETH Zurich

______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com