similar to: LAPACK package

Hi All, This is my R-version information:--- > version _ platform i486-pc-linux-gnu arch i486 os linux-gnu system i486, linux-gnu status major 2 minor 7.1 year 2008 month 06 day 23 svn rev 45970 language R version.string R version 2.7.1 (2008-06-23) While calculating partial

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

rvaradhan at jhmi.edu wrote: > 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: Thanks, but there seems to be a much easier fix. Inside coef.qr, we have coef[qr$pivot, ] <- .Call("qr_coef_real", qr, y, PACKAGE =

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

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

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

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

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,

Hi I have a problem with this error, I have searched the archives and found previous discussion about this, can I cannot understand how the explanations apply to what I am trying to do. I am trying to do Log_rank Survival analysis, I have included tables and str command, is it a factor/integer problem? If so how do I correct this, as all my attempt to recode the data have failed. >

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

The solve function in r-patched has been changed so that it applies a tolerance when using Lapack routines to calculate the inverse of a matrix or to solve a system of linear equations. A tolerance has always been used with the Linpack routines but not with the Lapack routines in versions 1.7.x and 1.8.0. (You can use the optional argument tol = 0 to override this check for computational

Hey Everyone, I'm running R 2.4.0 on Debian etch 4.0, and I'm trying to call some LAPACK functions from the C code in my package. Actually, to be honest I'm not really having trouble using commands such as La_dgesv from within my C code, but I do get warning when compiling the package saying: ***.c: In function '***': ***.c:37: warning: implicit declaration of function

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

After fixing princomp(), recently, {tiny negative eigen-values are possible for non-negative definite matrices} Fritz Leisch drew my attention to the fact the not only eigen() can be funny, but also svd(). Adrian Trappleti found that the singular values returned can be "-0" instead of "0". This will be a problem in something like sd <- svd(Mat) $ d

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 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 just detected, that det() is not working on complex matrices any more, due to the fix to the bug reports noted above. I am not happy with this, as determinants are perfectly usable on complex matrices. AFAIUI the bugs resulted from less than optimal behaviour of qr() in certain cases. IMHO this is due to the unhappy decision to use a default for parameter tol to decide whether the the

Dear BioConductor and R fellow users I apologize in advance for double posting, but I am not sure which list would actually be best fit for this message. I am experiencing a weird error with my R installation on Ubuntu 10.04.4 (LTS) 64bit: When I run R on the terminal everything goes smoothly: $R R version 2.15.2 (2012-10-26) -- "Trick or Treat" Copyright (C) 2012 The R Foundation

Hi Ricky / AJ Progress of sorts. I got passed the last problem by looking at the makefiles but run in to the next one, see below. It has created files in /contrib/R-2.4.0. there is an " R " under /contrib/R-2.4.0/bin/R. Running it gives :- /contrib/R-2.4.0/bin/R R version 2.4.0 (2006-10-03) Copyright (C) 2006 The R Foundation for Statistical Computing ISBN 3-900051-07-0 R is