similar to: min(numeric(0)) = ? -- proposal for "S incompatible change"

Dear all, in R 3.1.0, this is happening: > cummin(c(1+1i,2-3i,4+5i)) Error in cummin(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 'cummax' not defined for complex numbers > cummax(c(1+1i,2-3i,4+5i)) Error in cummax(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 'cummin' not defined for complex numbers It may be fixed in R-devel, but I thought I'd mention it to make sure

Hi, The function cummax() seems to have a bug. > x <- c(NA, 0) > storage.mode(x) <- "integer" > cummax(x) [1] NA 0 The correct result of this case should be NA NA. The mistake in [ https://github.com/wch/r-source/blob/trunk/src/main/cum.c#L130-L136] may be the reason. Best Regards, Dongcan -- Dongcan Jiang Team of Search Engine & Web Mining School of Electronic

Well, R ( http://lib.stat.cmu.edu/R/CRAN/ ) has a pictex(..) driver. >>>>> "kjetil" == kjetil halvorsen <kjetil@caoba.entelnet.bo> writes: kjetil> Is there any possibility to write code which ``translates'' kjetil> from splus graphics to latex picture commands? Or somebody has kjetil> written something like that? kjetil> I did

Looking into several different parts of R../src/library/base/R/*.R has led me to the conclusion that quite a bit of code doubling could be saved by using the following two functions whose naming philosophy is derived from that of NROW() & NCOL(): COLNAMES <- function(x) if(is.null(n <- colnames(x))) paste(seq(length=NCOL(x))) else n ROWNAMES <- function(x)

[I think Doug Bates has already alluded to this, somewhere..] In R, data.frame( ... ) does not construct row.names whereas in S, it does: R: > data.frame(x=1:2,y=3:4) x y [1,] 1 3 [2,] 2 4 > row.names(data.frame(x=1:2,y=3:4)) NULL S-plus: > data.frame(x=1:2,y=3:4) x y 1 1 3 2 2 4 > row.names(data.frame(x=1:2,y=3:4)) [1] "1" "2"

Hi, I have two questions want to ask. 1. If I have a matrix like this, and I want to figure out the rows whose value in the 3rd column are less than 0.05. How can I do it with R. hsa-let-7a--MBTD1 0.528239197 2.41E-05 hsa-let-7a--APOBEC1 0.507869409 5.51E-05 hsa-let-7a--PAPOLA 0.470451884 0.000221774 hsa-let-7a--NF2 0.469280186 0.000231065 hsa-let-7a--SLC17A5

In order to run some R examples in S & Splus, I want the gl() function in S. In R, it is gl <- function (n, k, length = n * k, labels = 1:n, ordered = FALSE) factor(rep(rep(1:n, rep(k, n)), length = length), labels = labels, ordered = ordered) Since S's factor() has no "ordered= F" argument, in S we need to call ordered() instead of factor() in the case of

Our main server [www/ftp/mail] "stat.ethz.ch" (if you want to ping) will be getting more RAM, new disks with new filesystems, etc. This will start on Saturday July 24, 10:30 GMT+2 (=MEST) and last several hours. In case it would take more than 4 hours or so, you might get messages back that you sent to the mailing lists R-help, R-devel, R-announce or R-core. DO NOT REPOST THEM, since

The big Swiss University network provider has been having severe problems for about 8 hours now --- particularly the cross-atlantic connection seems broken --- Many of you will get R-help or ESS-help E-mails very much delayed. Hope things start working soon by themselves. [for those that are disrupted: When you get this message, things should be back to normal; otherwise you wouldn't have

>>>>> "TL" == Thomas Lumley <thomas@biostat.washington.edu> writes: TL> ...... TL> Currently "%*%" doesn't have any help but help TL> requests get routed to Arith, because "%*%" as a regular expression TL> matches "%%". I will add this to the special cases in help(), but TL> should we use fgrep

The reason being a design decision of a while ago that "T" and "F" shouldn't be reserved words in R as they are in S-plus. Hence, T & F are just variables being set to TRUE and FALSE respectively; they *can* be overwritten by the user which is very useful e.g., when you do mydat <- read.table(file, header =TRUE) and the file has variable names "T" or

[CC'ed to R-devel, since it should be of interest to more ..] >>>>> "Guy" == Guy Nason <G.P.Nason@Bristol.ac.uk> writes: Guy> Dear Martin, Hope you are well. I am trying to start to get my Guy> [new] WaveThresh package working for R. Great, thank you! Can you make sure that your Examples (.EX in S syntax; \examples{..} in *.Rd) are directly

R 0.63 only ------------ (0.62 does not have the print-tests.Rout.save against which to diff!) I'd be glad if some of you could help us find out some printing/formatting differences of the same R version on different architectures. I have the suspiscion that the new glibc aka libc-6 (Linux), has changed some of the internal printing/formatting code [fprintf ..]. One consequence is that

As some of you know, we have been thinking of allowing the possibility of a CHOICE of the kind of random number generator (=: RNG) to use in R. The current R-release snapshot even has some code in it; however, this will be changed quite a bit. Here is a kind of informal RFC (request for comments / request for criticism / ..): 1a. With the new scheme, we still want that save(..) &

As just mentioned on R-devel, and originally reported (somewhat less concisely) by Adrian Trapletti, This code write(c(paste("\"", LETTERS[1:3],"\"", sep=""),1:3), nc=3) scan("data") # gives error as it should count.fields("data") # will be wrong count.fields("data") # is now ok : 3 3 gives (in 0.64.2 and in 0.65

Dear Prof Azzalini, You have an interesting example of recursive use of uniroot(). [re-cited at the end] However, note that R currently has the same problem as S-plus: Uniroot() doesn't work reliably, recursively. When you found it to be better, you were just lucky. The relevant file in R's source, src/main/optimize.c says /* WARNING : As things stand, these routines should

This was ``accidentally'' only sent to me. But I think the question (and possibly answers) should be relevant to much more people! >> To: maechler at stat.math.ethz.ch >> Subject: manual >> From: Pat Altham <P.M.E.Altham at statslab.cam.ac.uk> >> Date: Thu, 13 Aug 1998 11:34:31 +0100 >> >> Could you kindly email me (or tell me how to obtain)

[forwarded to R-devel, where this really belongs] >>>>> "Samira" == Samira M Ismail <samira@ime.unicamp.br> writes: (to me in a private mail) Samira> We have been trying to install R.0.63 for Unix (SunOS 4.1.4 - Samira> SPARC 20) and we detected the following problem which makes Samira> impossible to run R. We have got the following message:

In R and S, the general idea is that data.frames must have unique row.names (aka dimnames(.)[[1]]). Several observations / problems (in R *and* S !). [Example code at the end] 1) Both in S and R, data.frame(..) (and e.g., also cbind(<data.frame>, ..) which dispatches to data.frame()) silently drops the whole row.names and replaces it by "1" "2" ...

i) (function(x, ...) length(...))(1) gives 0 in S (plus 3.4) and an error in R. It also gives an error in Splus 5.0r3. So we could well remain as we are... however ii) (function(x, ...) length(...))(1,2) gives 1 in all dialects of S that I have available. So by my `continuation logic', I'd argue that "i)" above should give 0 (and R and S-plus 5.0r3 behave