similar to: data.frame(...) not constructing "1:n" row.names [diff. S <--> R]

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" ...

>>>>> "JonR" == Jonathan Rougier <J.C.Rougier@durham.ac.uk> writes: JonR> ... By the way, I have `solve' JonR> methods for triangular matrices and variance matrices -- would JonR> you be interested? { Jonathan, I hope it's okay if I CC this to R-devel; this must be of a wider interest } Ye.e..s; for triangular ones,

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

[Same question for max(.), cummin(.) and cummax(.)] In S, S-plus and R, this currently gives NA. I wonder if it wouldn't make more sense to follow common mathematical/logical reasoning here: min { empty set } = +Inf max { empty set } = -Inf (For integers, these would be INT_MAX and INT_MIN, respectively). Maybe this is a real ``first time'': I am proposing a change which

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

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

(following up on myself:) >>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: MM> In R and S, the general idea is that data.frames MM> must have unique row.names (aka dimnames(.)[[1]]). MM> Several observations / problems (in R *and* S !). .... MM> 2) MM> Now, in S (but not in R), MM> the

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

Hi Martin et al. Sorry for not getting back onto this sooner. I've been pretty well buried under travel plus being sick for a bit, but I will be happy to roll up a patch for this, including documentation and put it into a wishlist item. I'll aim to do that at some point next week. Thanks @Martin Maechler <maechler at stat.math.ethz.ch> for engaging with us and being willing to

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)

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)

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

[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: