similar to: Inefficiency in df$col

Does either of you have a patch against current R-devel? I tried the obvious, but the build dies with building package 'tools' all.R is unchanged ../../../../library/tools/libs/x86_64/tools.so is unchanged installing 'sysdata.rda' Error in get(method, envir = home) : object '$.data.frame' not found Error: unable to load R code in package 'tools' Execution halted

While doing some performance testing with the new version of pqR (see pqR-project.org), I've encountered an extreme, and quite unnecessary, inefficiency in the current R Core implementation of R, which I think you might want to correct. The inefficiency is in access to columns of a data frame, as in expressions such as df$col[i], which I think are very common (the alternatives of

>>>>> peter dalgaard >>>>> on Mon, 4 Feb 2019 16:48:12 +0100 writes: > Does either of you have a patch against current R-devel? > I tried the obvious, but the build dies with > building package 'tools' > all.R is unchanged > ../../../../library/tools/libs/x86_64/tools.so is unchanged > installing

On 04/02/2019 9:20 a.m., Radford Neal wrote: >>> I think you might want to just delete the definition of $.data.frame, >>> reverting to the situation before R-3.1.0. >> >> I imagine the cause is that the list version is done in C code rather >> than R code (i.e. there's no R function `$.list`). So an alternative >> solution would be to also implement

> From: Richard Cotton <richierocks at gmail.com> > > The rep function is very versatile, but that versatility comes at a > cost: it takes a bit of effort to learn (and remember) its syntax. > This is a problem, since rep is one of the first functions many > beginners will come across. Of the three main uses of rep, two have > simpler alternatives. > > rep(x,

A new version of pqR is now available at pqR-project.org, which fixes several bugs that are also present in the latest R Core patch release (r66002). A number of bugs found previously during pqR development are also unfixed in the latest R Core release. Here is the list of these bugs that are unfixed in r66002 (including documentation deficiencies), taken from the pqR bug fix and documentation

I've continued to work on speeding up R, and now have a collection of fourteen patches, some of which speed up particular functions, and some of which reduce general interpretive overhead. The total speed improvement from these patches is substantial. It varies a lot from one R program to the next, of course, and probably from one machine to the next, but speedups of 25% can be expected in

The current R release candidate has a lack of protect bug (of very long standing) with respect to the R_print.na_string and R_print.na_string_noquote fields of the static R_print structure declared in Print.h. This shows up very occassionally as incorrect output from the following lines in reg-tests-2.R: x <- c("a", NA, "b") factor(x) factor(x, exclude="")

In testing pqR on Solaris SPARC systems, I have found two bugs that are also present in recent R Core versions. You can see the bugs and fixes at the following URLs: https://github.com/radfordneal/pqR/commit/739a4960a4d8f3a3b20cfc311518369576689f37 https://github.com/radfordneal/pqR/commit/339b7286c7b43dcc6b00e51515772f1d7dce7858 The first bug, in nls, is most likely to occur on a 64-bit

http://stackoverflow.com/questions/6065724/assigning-value-to-a-variable-that-has-a-dot-in-the-name made me realize this. The context is 'a' is assigned to ret$log.id, but then ret$log returns "a" and ret$l also returns "a". There is a comment from Charles on the question: "Also see options(warnPartialMatchDollar=T) if you want to track these." But, in

> I propose a patch to ifelse that leverages anyNA(test) to achieve an > improvement in performance. For a test vector of length 10, the change > nearly halves the time taken and for a test of length 1 million, there > is a tenfold increase in speed. Even for small vectors, the > distributions of timings between the old and the proposed ifelse do > not intersect. For smaller

I've been getting pqR to work on windows systems, and in the process have discovered various problems with R core versions of R and with Rtools. One is with the implementation of OpenMP in 64-bit Rtools. This problem is in Rtools215 and Rtools33, and presumably all the ones in between. You can see the problem with the following test program: #include <stdio.h> #include <omp.h>

Gabriel Becker writes: AFAIK R does not automatically copy function arguments. R actually tries very hard to avoid copying while maintaining "pass by value" functionality. ... R only copies data when you modify an object, not when you simply pass it to a function. This is a bit misleading. R tries to avoid copying by maintaining a count of how many references there are to an

> > The current R release candidate has a lack of protect bug > > (of very long standing) > > [ but not really reported, right ? ] It's "long standing" because it exists in versions of R going back many years. > but the R 3.2.1 release candidate probably really cannot be > touched now, with something non-trivial like this. > > We'd be

Regarding Tengfei Yin's post about an error trying to install "cluster" in 2.13.0, I have gotten an error with this package when trying to install the released version of 2.12.0. Here is the output on an Ubuntu Linux system: begin installing recommended package cluster * installing *source* package 'cluster' ... ** libs make[3]: Entering directory

> Radford Nea: > > So it may make more sense to move towards consistency in the > > permissive direction, rather than the restrictive direction. > > > That would mean allowing matrix(1,1,1) < (1:2), and maybe also things > > like matrix(1,2,2)+(1:8). > > Martin Maechler: > That is an interesting idea. Yes, in my view that would >

The statement in R devel: There is no \code{data.frame} method for \code{$}, so \code{x$name} uses the default method which treats \code{x} as a list (with no partial matching of column names). The replacement method (for \code{$}) checks \code{value} for the correct number of rows, and replicates it if necessary. The added "(with no partial matching of column names)" is wrong.

> ... with assignments inside of loops like this: > > reweight = function(iter, w, Q) { > for (i in 1:iter) { > wT = w * Q > } > } > ... before the RHS is executed, the LHS allocation would be added > to a small fixed length list of available space which is checked > before future allocations. If the same size is requested before the > next garbage

> On Wed, 14 Jun 2017, G?bor Cs?rdi wrote: > > > I like the idea of string literals, but the C/C++ way clearly does not > > work. The Python/Julia way might, i.e.: > > > > """this is a > > multi-line > > lineral""" > > luke-tierney at uiowa.edu: > This does look like a promising option; some more careful checking

> Then the question would be if this test could be replaced with a new > argument to sample, e.g. expandSingle, which has TRUE as default for > backward compatibility, but FALSE if you dont want population to be > expanded to 1:population. It could certainly be useful in some cases, > but you still need to know about the expansion to use it. I think most > of these bugs