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

[ProfJCNash]

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 <pdalgd at 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 <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
>>
>>
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>