Re: [Rd] R 2.11.0 on RHEL5
Thank you for your response. I did look in the suggested manual under A.3.1.5 Shared BLAS. Here are my steps: compiled R using --with-readline=yes --enable-R-shlib=yes --enable-BLAS-shlib=yes --with-x=yes --prefix=/usr/local/R-2.11.0 Compiled LAPACK first and then ATLAS using http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063cceee2cc6313c All the .so files have been copied to /usr/lib64 In /usr/local/R-2.11.0/lib64/R/lib, I renamed the .so files for blas and lapack and linked as libRblas.so -> /usr/local/lib64/libf77blas.so libRlapack.so -> /usr/local/lib64/liblapack.so R does startup OK but when I do the following: require(nlme) fm1 <- nlme(height ~ SSasymp(age, Asym, R0, lrc), data = Loblolly, fixed = Asym + R0 + lrc ~ 1, random = Asym ~ 1, start = c(Asym = 103, R0 = -8.5, lrc = -3.3)) I get /usr/local/R-2.11.0/lib64/R/bin/exec/R: symbol lookup error: /usr/local/R-2.11.0/lib64/R/lib/libRblas.so: undefined symbol: ATL_dgemm This runs just fine without using the .so files which were built with R. Can you please help? Thanks. Uwe Ligges wrote: > This is explained in detail in the manual "R Installation and > Administration". > > Best, > Uwe Ligges > > > On 03.05.2010 06:02, Chuck White wrote: > > I have built lapack-3.2 and atlas3.8.3 for a RHEL5.3 VM. The following > > files have been created -- libatlas (.a& .so), libcblas (.a& .so), > > libf77blas (.a& .so), liblapack (.a& .so), libptcblas (.a& .so), > > libptf77blas (.a& .so) and libstatatlas.a. > > > > When building R 2.11.0, I would like to be able to specify --with-blas and > > --with-lapack (and not use the ones which come with R). What is the syntax > > for that? Which of these libraries should I specify? > > > > Thanks. > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] split() bug? Inconsistent Windows/Linux behavior.
This is now fixed in R-devel (revision 51908), and R-patched (r51909). Thanks Jay for the nice reproducible example, and thanks Matt for localizing it to the interaction() function. Duncan Murdoch On 04/05/2010 4:37 PM, Jay Emerson wrote: I didn't see anything on this in the bug reports, and a search of the archives had lots of false positives when searching on "split" to be helpful. I don't view this as particularly interesting or useful, but wanted to report it because I stumbled on it (and don't remember ever seeing "invalid permissions" as part of a segfault). Yes, I realize this is a silly example that you wouldn't actually do, but... there may be other more interesting cases with the same problem. The following was R-2.10.0 on Linux (with a Windows-64 2.11.0 difference to follow below): data(iris) split(1:nrow(iris), list(iris[,1], iris[,2])) *** caught segfault *** address 0x7fc806cd3d0c, cause 'invalid permissions' Traceback: 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) 2: split(1:nrow(iris), list(iris[, 1], iris[, 2])) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace In contrast, R-2.11.0 in Windows-64: data(iris) split(1:nrow(iris), list(iris[,1], iris[,2])) Traceback: 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) 2: split(1:nrow(iris), list(iris[, 1], iris[, 2])) Error in split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) : caught access violation - continue with care However, the same commands with drop=TRUE returns something, though the answers differ. In Linux: a <- split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE) length(a) [1] 116 And in Windows, differing only in the extra returned element, which I don't think should probably be part of the answer (there are no missing values in the iris data): a <- split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE) length(a) [1] 117 a[117] $ [1] 16 -- John W. Emerson (Jay) Associate Professor of Statistics Department of Statistics Yale University http://www.stat.yale.edu/~jay __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] split() bug? Inconsistent Windows/Linux behavior.
On 04/05/2010 6:45 PM, Matt Shotwell wrote: This is odd, I think it may have something to do with this Yes, it's definitely a bug in interaction() rather than split() per se. I'll take a look and see if I can fix it. Duncan Murdoch f <- interaction(list(iris[,1], iris[,2])) f[16] [1] unclass(f)[16] [1] 785 nlevels(f) [1] 781 Maybe do_split dereferencing beyond allocated memory? interaction(list(iris[,1], iris[,2]), sep="-") does not produce at index 16 -Matt On Tue, 2010-05-04 at 16:37 -0400, Jay Emerson wrote: I didn't see anything on this in the bug reports, and a search of the archives had lots of false positives when searching on "split" to be helpful. I don't view this as particularly interesting or useful, but wanted to report it because I stumbled on it (and don't remember ever seeing "invalid permissions" as part of a segfault). Yes, I realize this is a silly example that you wouldn't actually do, but... there may be other more interesting cases with the same problem. The following was R-2.10.0 on Linux (with a Windows-64 2.11.0 difference to follow below): data(iris) split(1:nrow(iris), list(iris[,1], iris[,2])) *** caught segfault *** address 0x7fc806cd3d0c, cause 'invalid permissions' Traceback: 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) 2: split(1:nrow(iris), list(iris[, 1], iris[, 2])) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace In contrast, R-2.11.0 in Windows-64: data(iris) split(1:nrow(iris), list(iris[,1], iris[,2])) Traceback: 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) 2: split(1:nrow(iris), list(iris[, 1], iris[, 2])) Error in split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) : caught access violation - continue with care However, the same commands with drop=TRUE returns something, though the answers differ. In Linux: a <- split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE) length(a) [1] 116 And in Windows, differing only in the extra returned element, which I don't think should probably be part of the answer (there are no missing values in the iris data): a <- split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE) length(a) [1] 117 a[117] $ [1] 16 -- John W. Emerson (Jay) Associate Professor of Statistics Department of Statistics Yale University http://www.stat.yale.edu/~jay __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] split() bug? Inconsistent Windows/Linux behavior.
This is odd, I think it may have something to do with this > f <- interaction(list(iris[,1], iris[,2])) > f[16] [1] > unclass(f)[16] [1] 785 > nlevels(f) [1] 781 Maybe do_split dereferencing beyond allocated memory? > interaction(list(iris[,1], iris[,2]), sep="-") does not produce at index 16 -Matt On Tue, 2010-05-04 at 16:37 -0400, Jay Emerson wrote: > I didn't see anything on this in the bug reports, and a search of the > archives had lots of false positives when searching on "split" to be > helpful. > > I don't view this as particularly interesting or useful, but wanted to > report it because I stumbled on it (and don't remember ever seeing > "invalid permissions" as part of a segfault). Yes, I realize this is > a silly example that you wouldn't actually do, but... there may be > other more interesting cases with the same problem. The following was > R-2.10.0 on Linux (with a Windows-64 2.11.0 difference to follow > below): > > > data(iris) > > split(1:nrow(iris), list(iris[,1], iris[,2])) > > *** caught segfault *** > address 0x7fc806cd3d0c, cause 'invalid permissions' > > Traceback: > 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) > 2: split(1:nrow(iris), list(iris[, 1], iris[, 2])) > > Possible actions: > 1: abort (with core dump, if enabled) > 2: normal R exit > 3: exit R without saving workspace > 4: exit R saving workspace > > In contrast, R-2.11.0 in Windows-64: > > > data(iris) > > split(1:nrow(iris), list(iris[,1], iris[,2])) > > Traceback: > 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) > 2: split(1:nrow(iris), list(iris[, 1], iris[, 2])) > Error in split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) : > caught access violation - continue with care > > However, the same commands with drop=TRUE returns something, though > the answers differ. In Linux: > > > a <- split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE) > > length(a) > [1] 116 > > And in Windows, differing only in the extra returned element, which I > don't think should probably be part of the answer (there are no > missing values in the iris data): > > > a <- split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE) > > length(a) > [1] 117 > > a[117] > $ > [1] 16 > > -- > John W. Emerson (Jay) > Associate Professor of Statistics > Department of Statistics > Yale University > http://www.stat.yale.edu/~jay > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] split() bug? Inconsistent Windows/Linux behavior.
I didn't see anything on this in the bug reports, and a search of the archives had lots of false positives when searching on "split" to be helpful. I don't view this as particularly interesting or useful, but wanted to report it because I stumbled on it (and don't remember ever seeing "invalid permissions" as part of a segfault). Yes, I realize this is a silly example that you wouldn't actually do, but... there may be other more interesting cases with the same problem. The following was R-2.10.0 on Linux (with a Windows-64 2.11.0 difference to follow below): > data(iris) > split(1:nrow(iris), list(iris[,1], iris[,2])) *** caught segfault *** address 0x7fc806cd3d0c, cause 'invalid permissions' Traceback: 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) 2: split(1:nrow(iris), list(iris[, 1], iris[, 2])) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace In contrast, R-2.11.0 in Windows-64: > data(iris) > split(1:nrow(iris), list(iris[,1], iris[,2])) Traceback: 1: split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) 2: split(1:nrow(iris), list(iris[, 1], iris[, 2])) Error in split.default(1:nrow(iris), list(iris[, 1], iris[, 2])) : caught access violation - continue with care However, the same commands with drop=TRUE returns something, though the answers differ. In Linux: > a <- split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE) > length(a) [1] 116 And in Windows, differing only in the extra returned element, which I don't think should probably be part of the answer (there are no missing values in the iris data): > a <- split(1:nrow(iris), list(iris[,1], iris[,2]), drop=TRUE) > length(a) [1] 117 > a[117] $ [1] 16 -- John W. Emerson (Jay) Associate Professor of Statistics Department of Statistics Yale University http://www.stat.yale.edu/~jay __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] automatically loading packages
If I start an R session with a previously saved .RData that has S4 objects in it, there are times when the associated package loads when I use (or mention) the object, and times when it doesn't. For example: > dim(casesIn) NULL > library(sp) > dim(casesIn) [1] 726 22 - because casesIn is a SpatialPointsDataFrame. But if I try and plot it (starting from scratch again), it loads the sp package: > plot(casesIn) Loading required package: sp - and then falls over: Error in as.double(y) : cannot coerce type 'S4' to vector of type 'double' - which is the error you get from plot.default(casesIn). Trying plot(casesIn) again then works, producing a point map. Why doesn't it work the first time? dim(casesIn) never triggers a library(sp) call: > dim(casesIn) NULL - so do it manually: > library(sp) > dim(casesIn) [1] 726 22 - I guess it must depend on whether its a generic of S3 or S4 flavour and/or the current phase of the moon. I can't find any information about this behaviour, and I can't think of a good query to search for it either. I keep hitting the 'autoload' documentation, which seems to be something completely different. R 2.10.1 on Linux - can't see anything relevant in the latest NEWS file. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
