similar to: qr(x,LAPACK=TRUE) (PR#2867)

This is a multipart message in MIME format. --=_alternative 00812CFCCA256D66_= Content-Type: text/plain; charset="us-ascii" Two points in respect to PR#2867. First, the trivial one: (1) In Lapack.c, on lines 806 and 812, there are calls of F77_CALL(dgeqp3). But the error messages on lines on lines 809 and 815 refer to "dqeqp3", i.e., they currently have a "q"

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

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 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 computed by the decomposition(*): always full rank in the LAPACK case. For a me a "full rank matrix" is a matrix the rank of which is indeed min(nrow(A), ncol(A)) but here the meaning of "always is full rank" is somewhat confusing. Does it

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

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

This behavior is noted in the qr documentation, no? rank - the rank of x as computed by the decomposition(*): always full rank in the LAPACK case. > On Jan 22, 2018, at 11:21 AM, Serguei Sokol <sokol at insa-toulouse.fr> wrote: > > Hi, > > I have noticed different rank values calculated by qr() depending on > LAPACK parameter. When it is FALSE (default) a true rank is

>>>>> 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 computed by the decomposition(*): always full rank in the LAPACK case. > For a

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

Full_Name: Mark MacLennan Version: 1.7.1 OS: Solaris 8 Submission from: (NULL) (216.17.17.197) Bug PR#2867 appears to still be occurring ... I am running Solaris 8 using gcc 3.3 and while running the tests for R 1.7.1 I get the following error message regarding Lapack routine dqeqp3 I don't know how serious an issue this is! Thanks for any help! Mark ----- running code in

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

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

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

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:

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

mgcv 1.0 (package providing gams etc) will be released with R 1.9.0. (R 1.8.x compatible versions can be found at: http://www.stats.gla.ac.uk/~simon/simon/mgcv.html) There are quite a few changes from mgcv 0.9: hence this message. The main new features are: * A generalized additive mixed modelling function `gamm' (which uses lme from the nlme library of glmmPQL from the MASS library for

mgcv 1.0 (package providing gams etc) will be released with R 1.9.0. (R 1.8.x compatible versions can be found at: http://www.stats.gla.ac.uk/~simon/simon/mgcv.html) There are quite a few changes from mgcv 0.9: hence this message. The main new features are: * A generalized additive mixed modelling function `gamm' (which uses lme from the nlme library of glmmPQL from the MASS library for

mgcv version 1.2 is on CRAN now. mgcv provides generalized additive models and generalized additive mixed models with automatic estimation of the smoothness of model components. Changes in this version are: * A new gam fitting method is implemented for the generalized case. It provides more reliable convergence than the previous default, but can be a little slower. See ?gam.method,

mgcv version 1.2 is on CRAN now. mgcv provides generalized additive models and generalized additive mixed models with automatic estimation of the smoothness of model components. Changes in this version are: * A new gam fitting method is implemented for the generalized case. It provides more reliable convergence than the previous default, but can be a little slower. See ?gam.method,