Closely related to the different QR variations, Claudia Beleites and I have a very crude start on some attempts to categorize different svd approaches in R. Perhaps it's worth combining efforts with QR because of the overlap and producing a sort of enlarged vignette or even a Task View. I suggest contacting me offline (I use nashjc _at_ uottawa.ca as my working email, and the one above for mailing lists) if interested. However, I view my current effort as a useful ongoing set of notes rather than a definitive treatment of the issues.
Best, JN On 16-08-03 09:16 AM, Charles Determan wrote: > Thanks for the input Peter. I suppose I never looked at lm() to see how it > was used there. Given that though, do you see any reason then to not > create an S3/S4 method if different methods are used for different > functions? I'm just looking for some design guidance from the community > here before I just implement something that may cause more confusion. > > Regards, > Charles > > On Tue, Aug 2, 2016 at 4:34 PM, Peter Dalgaard <pda...@gmail.com> wrote: > >> 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 <cdeterma...@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@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
