similar to: R/S indexing difference

(1) I do read the posting guide (the fact that I missread o missunderstood something does not imply not reading) (2) I could change NAs to 0 (I know) but I have previously (older versions of R and SQL*Plus) used the same select with the "right" output (namely with 0s). (3) AFAIK "strange" is not a negative remark and does not seem to me at the very least but that is always a

R 0.65.1 (and R-devel 09/11/99) > z <- data.frame(a=1:3) > b <- rep(NA, 3) > mode(b) [1] "logical" # how many of you expected that? I had forgotten! > zz <- cbind(z, b) > zz a b 1 1 NA 2 2 NA 3 3 NA > class(zz$b) [1] "factor" whereas in S it is NULL and zz$b is of mode "numeric". The same thing happens with data.frame zz <-

Apart from the inconsistencies, there are two clear bugs here: 1) miscalculating the number of values needed, in the matrix case. E.g. > AA[idx, 1] <- B[1:4] Error in "[<-"(`*tmp*`, idx, 1, value = B[1:4]) : number of items to replace is not a multiple of replacement length although only 4 values are replaced by AA[idx, 1] <- B. 2) the behaviour of the 3D case.

I have made the 3-d case do the same as the vector case, which is what the C code clearly intended (a goto label was in the wrong place). This leaves the bigger question of the right thing to do. I note that data frames give an error when any indices are NA. -thomas On Fri, 3 Sep 2004 ripley@stats.ox.ac.uk wrote: > Apart from the inconsistencies, there are two clear bugs here: > > 1)

There is something strange in R behaviour (perhaps). I have run the same select in Oracle SQL*Plus (version 10.1.0.2.0) and the output comes out with NULLs (which is what it ougth to be). But in R I still get the same result with NAs (no matter I use na.strings or nullstring arguments) An output example follows below: Using na.string="0" and nullstring="0" (sorry by the

As we have seen from PR#6846, we don't document much what happens to NAs in plot functions. The formula interfaces do seem to be a bit of a mess, as they call model.frame and so some (but only some) of them pick up the options() setting of na.action. This means that for example pairs(~ x +y + z) and pairs(cbind(x, y, z)) may well treat NAs differently, depending on the value of

On Thu, 9 Oct 2003 anaximander@gmx.de wrote: > Recursive indexing can cause R-1.8.0 (and R-1.7.1) to segment fault > > First of all, many thanks to the R team!! > R is really a software for everyday work. > Yes, I've found a fault, but I hope it's not just faultfinding ;-) > > In the NEWS file of R-1.8.0, first printed in R NEWS 1.7.1, > there was given a

Filing on R-bugs (DTL's reply started a new PR). -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ---------- Forwarded message

There is an even simpler way: someone wrote n*(n^2-1) as n*(n-1)*(n+1) and caused the problem. Your superfluous semicolons do definitely make your code harder to read. On Tue, 23 Aug 2005 jtk at cmp.uea.ac.uk wrote: > Full_Name: Jan T. Kim > Version: 2.1.0 (and better) > OS: Linux > Submission from: (NULL) (139.222.3.229) > > > The p value in Spearman's test is NA if

We've seen the integer overflow problem in ks.test before, easily solved. The help page says x and y must be numeric, so this is user error. I've added tests to the code. Why do people file bug reports without reading the help/man page? On Tue, 14 Jan 2003 bates@stat.wisc.edu wrote: > This was filed as a bug report on the Debian r-base package. It is > more properly a bug

On Thu, 30 Jan 2003 maechler@stat.math.ethz.ch wrote: > This is a bug that will not often trigger, and only happens for arrays > (but not matrices) ending up with 0 dimensions: The bug is a missing else branch of an if condition at line 431 of subset.c. I don't think the buglets are wrong. You don't drop length 0 dimensions. If you did, the object would be of the wrong length.

Please do as we ask (repeatedly) and study the help page before posting. 'family' is a separate argument, not part of loess.control, as the help page correctly documents. If you use cars.lo2 <- loess(dist ~ speed, cars, family = "symmetric", control = loess.control(surface = "direct", iterations = 20)) cars.lo2$pars$iterations it prints *20*, as it is

R 0.90.0: > Empl <- list(aa=1, b=2, c=3) > Empl[[as.numeric(NA)]] Error in Empl[[as.numeric(NA)]] : subscript out of bounds > Empl[[as.integer(NA)]] Error: attempt to select more than one element > Empl[[as.logical(NA)]] Error: attempt to select more than one element Now, (a) None of those messages is appropriate. (b) At least the first two should be the same. (c) S gives NULL

I used the packaged "MinGW-2.0.0-3.exe" exactly as specified on http://www.stats.ox.ac.uk/pub/Rtools/ - in fact I used these recommendations throughout. According to the release notes MinGW version 2.0.0 contains the following list of packages: GCC-3.2-core-20020817-1 binutils-2.13-20020903-1 mingw-runtime-2.2 w32api-2.0 gdb-5.1.1-1 make-3.79.1-20010722 (binary renamed as mingw32-make)

> BDR> You will need to call it something else: dist is a clone of an S > BDR> function, and dist(X, "manhattan") is well-established usage. > > one could still imagine an extra Y argument such that > dist(X, Y=myY, method="euclidean") > and dist(X, "euclidean", Y=myY) > would work > one could even make it such that > both

>>>>> "BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk> >>>>> on Fri, 30 May 2008 22:34:28 +0100 (BST) writes: BDR> I think it is ESS that is parsing this as a help BDR> request (so it can divert it to an ESS buffer). BDR> Looks like this is an ESS issue, not an R one. yes, indeed, hence much more belonging the ESS-help

Duncan, I don't know what we want, but it is not a simple matter of documenting what .dynLibs currently does. What I see as bugs are 1) the inconsistent names and types of the components returned by .dynLibs(). 2) the inconsistent inclusion or not of R_X11 in the list returned by .dynLibs(). 3) the inclusion of static info (base) by library.dynam(). 4) including loadable modules

Thanks for this clarification. I have learned in the meantime that it is necessary to be very careful when using all these POSIX things. As another example, here is something that made me scratch my head just yesterday: When I create a sequence of days that happens to start before and ends in daylight savings time, I seem to lose a day: > seq(from = strptime("20030329",

I have done a re-working of the time series code in base R and library ts that will appear in Friday's snapshot. I am sure at least one person will be dissatisfied, but I am convinced there are fewer errors than there were before (I found more than 20, as well as several documented features that did not exist.) The principles in the code are: tsp attributes can only go on vectors of length

On Wed, 5 Oct 2005 Hallgeir.Grinde at elkem.no wrote: > Yes. > so (x1*x2*x3*x4*x5*x6*x7*x8)^2 = (x1+x2+x3+x4+x5+x6+x7+x8)^8 ? Yes in the sense that the simplified formula given by terms() is the same. > and there is a difference in > (x1*x2*x3*x4*x5*x6*x7*x8)^2 > and > (x1*x2*x3*x4*x5*x6*x7*x8) > althoug the resulting formulas are the same, or? The first is reduced to the