[R-pkg-devel] Recommendation on qr method export

[Peter Dalgaard]

Not strictly what you're asking, but at some point it may be important to note that the "QR" method used by lm() and friends (notably anova() and aov()) actually relies on successive orthogonalization. This does yield a QR decomposition but the reverse is not true. A generic X=QR decomposition does orthogonalize, but it does not necessarily hold that the first k columns of Q spans the same subspace as the first k columns of X. LINPACK's QR happens to be implemented as successive orthogonalization, but LAPACK's is not, so only the former is usable with lm().

So, I suppose what I am getting at is that not even lm() uses qr(), it calls LINPACK directly.

-pd


> On 02 Aug 2016, at 21:17 , Charles Determan <cdetermanjr at gmail.com> wrote:
> 
> Hello,
> 
> I am currently working on an implementation of QR decomposition (leveraging
> a C++ library via Rcpp).  Naturally I would like to have the R syntax as
> similar as possible to base R 'qr' function.  Given the class structure of
> my package my instinct was to export an S4/S3 method.
> 
> However, the QR decomposition doesn't store the final QR matrix in the same
> format as base R via LINPACK, nor does it return 'qraux', 'rank' or 'pivot'
> objects but instead a 'betas' object.  The final 'R' and 'Q' matrices are
> in fact identical to those ultimately returned by qr.R or qr.Q.
> 
> So my question is, given these differences, should I just create a
> different function name or would creating a qr.myclass dispatch be
> acceptable (whether S3 or S4)?  I would prefer the latter as I would like
> the classes to potentially take advantage of previously written code using
> 'qr'.
> 
> Thanks,
> Charles
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel