similar to: follow-up on qr.coef bug (PR#8478)

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

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

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:

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

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

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)

> 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 ```

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 internally consistent, and another separate bug in the documentation. In particular, on

When creating a package, I would like a way to tell R that a function with a period in its name is not a method. I'm writing a package now with a modified version of qr.R. R CMD check gives warnings: * checking S3 generic/method consistency ... WARNING qr: function(x, ...) qr.R: function(qr, complete, pivot) See section ‘Generic functions and methods’ of the ‘Writing R Extensions’

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

Full_Name: Ravi Varadhan Version: 2.8.1 OS: Windows Submission from: (NULL) (162.129.251.19) Inverting a matrix with solve(), but using LAPACK=TRUE, gives erroneous results: Here is an example: hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") } h5 <- hilbert(5) hinv1 <- solve(qr(h5)) hinv2 <- solve(qr(h5, LAPACK=TRUE)) all.equal(hinv1, hinv2) #

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

Refiling this. The actual fix was slightly more complicated. Will soon be committed to R-Patched (aka 2.9.1 beta). -p rvaradhan at jhmi.edu wrote: > Full_Name: Ravi Varadhan > Version: 2.8.1 > OS: Windows > Submission from: (NULL) (162.129.251.19) >=20 >=20 > Inverting a matrix with solve(), but using LAPACK=3DTRUE, gives erroneo= us > results: Thanks, but there seems

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 <- >

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()

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))

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