similar to: NA values in indexing

I get this with R 2.7.2 (and 2.7.1, and 2.6.2, but NOT 2.4.0): > X11() # this one opens up okay > X11("foo") Error: Couldn't find per display information $ and R crashes out back to my shell prompt. If I do X11("foo") as a first command I get a meaningful error and my R prompt back: > X11("foo") Error in X11(d$display, d$width, d$height,

Dear R developers, I am having a slightly weird issue with a S4 method defined in my package adegenet 1.2-4, with R 2.11.0. As far as I know, the problem is new, and the code implementing the method has not changed for more than a year and worked well so far. The problem is the following. I define, in the package, a method "[" for the S4 class 'genind'. The method's

Dear R users, I'm a bit perplexed with the effect sort has here, as it is different on Windows vs. linux. It makes my factor levels and subsequent plots different on the two systems. Given: types <- c("PC-D-Euro-0", "PC-D-Euro-1", "PC-D-Euro-2", "PC-D-Euro-3", "PC-D-Euro-4", "PC-D-Euro-5", "PC-D-Euro-6",

Hi, I wonder if this is something on my machine locally or R in general. When I do the following: > plot(c(0,1),c(0,1),main=expression(paste(symbol("D"),"D",sep=""))) I get a plot with a title having uppercase delta followed by "D". But in the following > pdf(file="deltaTest.pdf") >

I'm guessing this is a FAQ but I can't find it and that it is probably not exclusive R related but relevant so I thought I'd ask: When I view the PDF output from Sweave (e.g. Example 1 from the author's web site at [1]) on a Linux system using the standard PDF viewer [2], the circles for the outliers in the plot [boxplot(Ozone ~ Month, data = airquality)] show up as the letter

Dear all, I am puzzled by the following behavior of the new grid.cap() function, which appears to run out of time when capturing the output of a graphic. It works fine if I introduce a Sys.sleep(1) before executing more code, library(grid) quartz() grid.circle(gp=gpar(fill="black")) gg <- grid.cap() dev.new() grid.raster(gg) ## completely blank gg[gg!="white"] ## indeed

Dear all, I got a couple of warnings using panel.levelplot.raster, In panel.levelplot.raster(..., interpolate = TRUE) : 'y' values are not equispaced; output will be wrong although I was quite sure my data were equally spaced (indeed, I created them with seq()). A closer look at the source code reveals that the function tests for exact uniformity in grid spacing, if

And for a starker example of this (documented) inconsistency, arithmetic addition is not commutative: > NA + NaN [1] NA > NaN + NA [1] NaN On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 02/07/2018 11:25 AM, Jan Gorecki wrote: >> Hi, >> base::mean is not consistent in terms of handling NA/NaN. >> Mean should not

On Mon, Feb 29, 2016 at 6:17 PM, John Chambers <jmc at r-project.org> wrote: > The Wikipedia statement may be a bit misleading. > > S was never open source. Source versions would only have been available with a nondisclosure agreement, and relatively few copies would have been distributed in source. There was a small but valuable "beta test" network, mainly university

(e-mailing to R-bugs is intentional - the web itnerface seems to be down) > a<- cbind(c(1,2), c(3,4)) > a [,1] [,2] [1,] 1 3 [2,] 2 4 > a[cbind(c(2,2), c(2,1))] [1] 4 2 > a[cbind(c(2,3), c(2,1))] Error: subscript out of bounds > a[cbind(c(2,-1), c(2,1))] Error: negative values are not allowed in a matrix subscript > a[cbind(c(2,0), c(2,1))] [1] 4 Am

Dear R devels Yesterday I was slightly surprised to notice that R incorrectly detected some of the locale settings. I am not sure whether this is important, but I preferred to drop a message. In the R output below, some entries that should have been "en_GB.UTF-8" are presented as "C". Regards Liviu > sessionInfo() R version 2.9.1 (2009-06-26) x86_64-pc-linux-gnu locale:

Hi List I have data in the following form: Gene    TFBS NUDC     PPARA(1) HNF4(20) HNF4(96) AHRARNT(104) CACBINDINGPROTEIN(149) T3R(167) HLF(191) RPA2     STAT4(57) HEB(251) TAF12     PAX3(53) YY1(92) BRCA(99) GLI(101) EIF3I     NERF(10) P300(10) TRAPPC3     HIC1(3) PAX5(17) PAX5(110) NRF1(119) HIC1(122) TRAPPC3     EGR(26) ZNF219(27) SP3(32) EGR(32) NFKAPPAB65(89) NFKAPPAB(89) RFX(121)

A colleague is receiving some data from another person. That person reads the data in SAS and it takes 30s and uses 64k RAM. That person then tries to read the data in R and it takes 10 minutes and uses a gigabyte of RAM. Person then goes on to say: It's not that I think SAS is such great software, it's not. But I really hate badly designed software. R is designed by

Hi all: we have noticed for quite a while that certain errors cannot be handled by R try, tryCatch etc blocks, but it was fairly difficult to understand what were the conditions for this incorrect behaviour. Finally I stabbed across a very understandable case, which is outlined in the (runnable) example below. The main message is: wrapping an S4 method call in a try block will not help if an

I don't think anyone denies that you *could* make an EXE to do all that. The discussion is on *how easy* it should be to create a single file that contains an initial "main" function plus a set of bundled code (potentially as a package) and which when run will install its package code (which is contained in itself, its not in a repo), install dependencies, and run the main()

I get an error when running "make check" after building R-devel r70629 on Ubuntu 14.04. Here are the relevant lines in the file "reg-tests-1c.Rout.fail": > ## m1z uses match(x, *) with length(x) == 1 and failed in R 3.3.0 > ## PR#16909 - a consequence of the match() bug; check here too: > dv <- data.frame(var?1 = 1:3, var?2 = 3); dv[,"var?2"]

On Thu, Jul 26, 2018 at 12:22 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: > I am trying to control a background R session, connected via a fifo / > named pipe. Is the fifo significant here? If I read the same R code from a file via `<` I get the input echoed (R 3.4.4, Ubuntu). Barry

Dear all, It seems that textConnection() can trigger a segmentation fault. The following script (using two large loops) makes this bug reproducible: for (i in 1:10000) { z=textConnection(NULL,open='w') for (j in 1:100) { write(runif(1)*1e6,file=z) write('\n',file=z) } close(z) } The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest R-devel

Dear All I posted a similar question quite some time ago, but that was on an old OS and an old version of R. This time I have RHEL 4, which is still supported as an OS, and R 2.5.1 which is not *that* old. My sessionInfo() gives: > sessionInfo() R version 2.5.1 (2007-06-27) i686-redhat-linux-gnu locale: LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.U

Yes, the performance overhead of fixing this at R level would be too large and it would complicate the code significantly. The result of binary operations involving NA and NaN is hardware dependent (the propagation of NaN payload) - on some hardware, it actually works the way we would like - NA is returned - but on some hardware you get NaN or sometimes NA and sometimes NaN. Also there are C