similar to: Need to tell R CMD check that a function qr.R is not a method

I suggest adding a 'pivot' argument to qr.R, to obtain columns in the same order as the original x, so that a <- qr(x) qr.Q(a) %*% qr.R(a, pivot=TRUE) returns x. -------------------------------------------------- # File src/library/base/R/qr.R qr.R <- function(qr, complete = FALSE, pivot = FALSE) { # Args: # qr: a QR decomposition, produced by qr() # complete:

The bug I submitted yesterday (It's not entered in the bug data base, so I have no ID for it) included a suggested fix that is not correct. It worked for the examples I gave because there was no pivoting in fact, or only pivot permutations that were idempotent. A correction that works in general on the examples I gave makes these two changes in qr.coef(): ## coef[qr$pivot, ]

The following snippet suggests that there is either a bug in qr(,LAPACK=T), or some bug in my understanding. Note that the detected rank is correct (= 2) using the default LINPACK qr, but incorrect (=3) using LAPACK. This is running on Linux Redhat 9.0, using the lapack library that comes with the Redhat distribution. I'm running R 1.7.1 compiled from the source. If the bug is in my

Hi, I think there is a problem with the LAPACK version of qr() in version 1.7.0. (version below). 1. The documentation states that LAPACK=TRUE is the default, but the code has LAPACK=FALSE. 2. With LAPACK=TRUE qr() is never pivoting, even in cases where it very clearly should be. e.g. set.seed(0) X<-matrix(rnorm(40),10,4);X[,1]<-X[,2] qrx<-qr(X,LAPACK=TRUE) qrx$pivot # note, no

Might it be possible to tighten the definition of "is.qr". I noticed that after I mistakenly typed example(lm) # make lm object named lm.D9 qr.Q(lm.D9) which exhausted the heap memory and produced two warning messages. As an object of class "lm" has a "qr" component, "is.qr" failed to detect that "lm.D9" was not a "qr" object. The

On Thu, 19 Apr 2007, brech at delphioutpost.com wrote: > Full_Name: Christian Brechbuehler > Version: 2.4.1 Patched (2007-03-25 r40917) > OS: Linux 2.6.15-27-adm64-xeon; Ubuntu 6.06.1 LTS > Submission from: (NULL) (24.61.47.236) > > > Splus and R have different ideas about what qr.coef(qr()) should return, > which is fine... but I believe that R has a bug in that it is not

> Date: Wed, 30 Jun 1999 11:12:24 +0200 (MET DST) > From: Torsten Hothorn <hothorn at amadeus.statistik.uni-dortmund.de> > > yesterday I had a little shock using qr (or lm). having a matrix > > X <- cbind(1,diag(3)) > y <- 1:3 > > the qr.coef returns one NA (because X is singular). So I computed the > Moore-Penrose inverse of X (just from the

man for `qr` says that the function uses LINPACK's DQRDC, while it in fact uses DQRDC2. ``` The QR decomposition of the matrix as computed by LINPACK or LAPACK. The components in the returned value correspond directly to the values returned by DQRDC/DGEQP3/ZGEQP3 ```

Here is a modified version of qraux.Rd, an edited version of R-2.14.0/src/library/base/man/qraux.Rd This gives some details and an example for the case of pivoting. In this case, it is not true that X = QR; rather X[, pivot] = QR. It may save some other people bugs and time to have this information. Tim Hesterberg -------------------------------------------------- % File

Hi, all. I want to write some functions like glm() so i studied it. In glm.fit(), it calls a fortran subroutine named "dqrfit" to compute least squares solutions to the system x * b = y To learn how "dqrfit" works, I just follow how glm() calls "dqrfit" by my own example, my codes are given below: > qr <- >

In summary.glm I'm trying to get a better feel for the z output. The following lines can be found in the function 1 if (p > 0) { 2 p1 <- 1:p 3 Qr <- object$qr 4 coef.p <- object$coefficients[Qr$pivot[p1]] 5 covmat.unscaled <- chol2inv(Qr$qr[p1, p1, drop = FALSE]) 6 dimnames(covmat.unscaled) <- list(names(coef.p), names(coef.p))

Dear maintainers, I'm reporting a bug in qr.coef that mishandles the colnames of matrix. A minimal reproducible example is as follows: x <- cbind(rep(0, 10), rep(0, 10)) y <- rep(0, 10) q <- qr.default(x) qr.coef(q, y) [1] NA NA If x has colnames, then qr.coef will end up with an error: x <- cbind(x1 = rep(0, 10), x2 = rep(0, 10)) y <- rep(0, 10) q <- qr.default(x)

Hello. I am trying to invert a matrix, and I am finding that I can get different answers depending on whether I set LAPACK true or false using "qr". I had understood that LAPACK is, in general more robust and faster than LINPACK, so I am confused as to why I am getting what seems to be invalid answers. The matrix is ostensibly the Hessian for a function I am optimizing. I want to get

G'day all, I had a look at the GLM code of R (1.4.1) and I believe that there are problems with the function "glm.fit" that may bite in rare circumstances. Note, I have no data set with which I ran into trouble. This report is solely based on having a look at the code. Below I append a listing of the glm.fit function as produced by my system. I have added line numbers so that I

I am testing 'qr' with an admittedly contrived matrix and I am getting different results than I am from another package. The matrix that I am using is: x <- matrix(seq(.1, by=.1, length.out=12), 4) So the whole test is: x <- matrix(seq(.1, by=.1, length.out=12), 4) qr(x) And the output from 'R' is: $qr [,1] [,2] [,3] [1,] -0.5477226 -1.2780193

Hi, I have noticed different rank values calculated by qr() depending on LAPACK parameter. When it is FALSE (default) a true rank is estimated and returned. Unfortunately, when LAPACK is set to TRUE, the min(nrow(A), ncol(A)) is returned which is only occasionally a true rank. Would not it be more consistent to replace the rank in the latter case by something based on the following pseudo code ?

I am using 2.2.0 If the QR decomposition of an N*M matrix is such that the pivoting order is not 1:M, Q%*%R does not result in the original matrix but in a matrix with the columns permuted. This is clearly intentional, and probably to be expected if pivoting is used --- chol() behaves in the same manner (it would perhaps be nice if the qr help page made that clear in the same way that the chol()

I think one needs an LU decomposition rather than QR. However, I couldn't find anything off the shelf to do an LU, other than learning that determinant() now uses LU instead of QR or SVD, so the code to do it must be in there for those that want it. You'll probably need to divide rows of U by the first entry if you insist on the unique reduced REF. However, I can't see any reason

Full_Name: Rick Sayre Version: 2.8.0 OS: windows, linux, os x Submission from: (NULL) (138.72.153.166) PR#8476 and PR#8478 http://bugs.r-project.org/cgi-bin/R/Models-fixed?id=8478 http://bugs.r-project.org/cgi-bin/R/Models-fixed?id=8476 discuss fixing qr.coef to handle complex matrices correctly But it appears the solution now "shipping" only handles square matrices. In 2.8.0 [linux,

[I thought I'd submitted this bug report some time ago, but it's never showed up on the bug tracking system, so I'm submitting again.] qr.solve() gives incorrect results when dealing with complex matrices or with qr objects that have been computed with LAPACK=TRUE, whenever the b argument has more than one column. This bug flows from qr.coef(), which has a similar problem. I believe