similar to: (PR#9623) qr.coef: permutes dimnames; inserts NA; promises

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

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)

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

[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

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,

> 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

With this example set.seed(123) A <- matrix(runif(40), nrow = 8) y <- 1:nrow(A) A.laqr <- qr(A, LAPACK=TRUE) both qr.qy(A.laqr,y) and qr.qty(A.laqr,y) give the respective error messages Error in qr.qy(A.laqr, y) : 'b' must be a numeric matrix Error in qr.qty(A.laqr, y) : 'b' must be a numeric matrix However when Lapack is not used as in A.liqr <- qr(A,

Dear R people, I do not have much knowledge about linear algebra but currently I need to understand what the function qr.qty is actually doing. The documentation states that it calculates t(Q) %*% y via a previously performed QR matrix decomposition. In order to do that, I tried following basic example: m<-matrix(c(1,0,0,0,1,0,0,0,1,0,0,1),ncol=3) # 4x3 matrix

Hi, Why the qr() produces a negative Q compared with Gram-Schmidt? (note example below, except Q[2,3]) Here is an example, I calculate the Q by Gram-Schmidt process and compare the output with qr.Q() a <- c(1,0,1) b <- c(1,0,0) c <- c(2,1,0) x <- matrix(c(a,b,c),3,3) ########################## # Gram-Schmidt ########################## A <- matrix(a,3,1) q1 <-

I have been struggling to find some informaation on what lm exactly does. I know it uses the QR decomp. However, I was recently faced with a somewhat badly scaled matrix and summary(lm) said Coefficients: ( 4 not defined because of singularities) does anyone know how lm chooses these 4 coef. is it forward building of the model --> drop last when qr sends a non full rank design matrix? My

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:

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

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

Ladies and Gentlemen, using > A <- structure(c(1, 0, 0, 3, 2, 1, 4, 5, -3, -2, 1, 0), .Dim = as.integer(c(3,4))) I get > dim(A) [1] 3 4 > qr.R(qr(A),complete=TRUE) [,1] [,2] [,3] [,4] [1,] -1 -3.000000 -4.000000 2.0000000 [2,] 0 -2.236068 -3.130495 -0.8944272 [3,] 0 0.000000 -4.919350 -0.4472136 > qr.R(qr(A),complete=FALSE) [,1]

Hello, I don't understand what went wrong or how to fix this. How do I set qr=TRUE for gam? When I produce a fit using gam like this: fit = gam(y~s(x),data=as.data.frame(l_yx),family=family,control = list(keepData=T)) ...then try to use predict: (see #1 below in the traceback() ) > traceback() 6: stop("lm object does not have a proper 'qr' component.\n Rank zero or should

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’

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 ?

Le 23/01/2018 ? 08:47, Martin Maechler a ?crit?: >>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>>> on Mon, 22 Jan 2018 17:57:47 +0100 writes: > > Le 22/01/2018 ? 17:40, Keith O'Hara a ?crit?: > >> This behavior is noted in the qr documentation, no? > >> > >> rank - the rank of x as

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

> Date: Mon, 1 May 2000 16:25:11 +0200 (CEST) > From: gb <gb at stat.umu.se> > > On 1 May 2000, Douglas Bates wrote: > > gb <gb at stat.umu.se> writes: > > > > > How about 'Ainv <- qr.solve(A)'? > > > > > > I happened to read the help page for 'qr.solve' the other day, and there I > > > found that