search for: evallist

...ng results that I wrote about on my blog at radfordneal.wordpress.com (see the posts on "Speeding up parentheses..." and "Two surprising things...". I discovered that the strange speed advantage of curly brackets over parentheses is partially explained by an inefficiency in the evalList and evalListKeepMissing procedures in eval.c, in directory src/main, which are on the critical path for many operations. These procedures unnecessarily allocate an extra CONS node. I rewrote them to avoid this, which seems to speed up a typical program by about 5% (assuming it doesn't spend m...

As I mentioned in my previous message about speeding up evalList, I've been looking at ways to speed up the R interpreter. One sees in the code many, many calls of PROTECT, UNPROTECT, and related functions, so that seems like an obvious target for optimization. Indeed, I've found that one can speed up the interpreter by about 10% by just changing these...

...ei. > > Yes, something like that seems even simpler than Peter's > suggestion... > > It currently breaks 'make check' in the R sources, > specifically in tests/reg-tests-2.R (lines 6574 ff), > the new code now gives > > > ## error messages from (C-level) evalList > > tst <- function(y) { stopifnot(is.numeric(y)); y+ 1 } > > try(tst()) > Error in eval(cl.i, pfr) : argument "y" is missing, with no default > > whereas previously it gave > > Error in stopifnot(is.numeric(y)) : > argument "y"...

...chDollar=TRUE) > pl <- pairlist(abc=1,def=2) > pl$ab [1] 1 Warning message: In pl$ab : partial match of 'ab' to '' Some code is changed at the end of R_subset3_dflt because it seems to be more correct, as discussed in code comments. patch-evalList Speeds up a large number of operations by avoiding allocation of an extra CONS cell in the procedures for evaluating argument lists. Relevant timing test scripts: all of them, but will look at test-em.r On test-em.r, the speedup from this patch is about 5%. patch-fast-base...

...>> suggestion... > >> > >> It currently breaks 'make check' in the R sources, > >> specifically in tests/reg-tests-2.R (lines 6574 ff), > >> the new code now gives > >> > >> > ## error messages from (C-level) evalList > >> > tst <- function(y) { stopifnot(is.numeric(y)); y+ 1 } > >> > try(tst()) > >> Error in eval(cl.i, pfr) : argument "y" is missing, with no default > >> > >> whereas previously it gave > >> > >&g...

...er than Peter's >> suggestion... >> >> It currently breaks 'make check' in the R sources, >> specifically in tests/reg-tests-2.R (lines 6574 ff), >> the new code now gives >> >> > ## error messages from (C-level) evalList >> > tst <- function(y) { stopifnot(is.numeric(y)); y+ 1 } >> > try(tst()) >> Error in eval(cl.i, pfr) : argument "y" is missing, with no default >> >> whereas previously it gave >> >> Error in stopifnot(is.n...

R> myfun <- function(x, ...) {x[...] <- 0; x} R> myfun(3) Error in myfun(3) : SubAssignArgs: invalid number of arguments It fails because no ... was passed. The workaround (and desired behavior) is: R> myfun <- function(x, ...) {if (missing(...)) x[] <- 0 else x[...] <- 0; x} R> myfun(3) [1] 0 Deja vu? This is the one piece of my PR#1110 (Oct 3, 2001) that I

I see that some of the speed patches that I posted have been incorporated into the current development version (eg, my patch-for, patch-evalList, and patch-vec-arith). My patch for speeding up x^2 has been addressed in an inadvisable way, however. This was a simple addition of four lines of code that speeds up squaring of real vectors by a factor of about six (for vectors of length 10000), by just converting x^2 to x*x. Modifications in...

...>>> >> It currently breaks 'make check' in the R sources, >>> >> specifically in tests/reg-tests-2.R (lines 6574 ff), >>> >> the new code now gives >>> >> >>> >> > ## error messages from (C-level) evalList >>> >> > tst <- function(y) { stopifnot(is.numeric(y)); y+ 1 } >>> >> > try(tst()) >>> >> Error in eval(cl.i, pfr) : argument "y" is missing, with no default >>> >> >>> >> whereas previ...

...chDollar=TRUE) > pl <- pairlist(abc=1,def=2) > pl$ab [1] 1 Warning message: In pl$ab : partial match of 'ab' to '' Some code is changed at the end of R_subset3_dflt because it seems to be more correct, as discussed in code comments. patch-evalList Speeds up a large number of operations by avoiding allocation of an extra CONS cell in the procedures for evaluating argument lists. Relevant timing test scripts: all of them, but will look at test-em.r On test-em.r, the speedup from this patch is about 5%. patch-fast-base...

...>> >> >> >> It currently breaks 'make check' in the R sources, >> >> specifically in tests/reg-tests-2.R (lines 6574 ff), >> >> the new code now gives >> >> >> >> > ## error messages from (C-level) evalList >> >> > tst <- function(y) { stopifnot(is.numeric(y)); y+ 1 } >> >> > try(tst()) >> >> Error in eval(cl.i, pfr) : argument "y" is missing, with no default >> >> >> >> whereas previously it gave >>...

...stop.R ] > Best, > Serguei. Yes, something like that seems even simpler than Peter's suggestion... It currently breaks 'make check' in the R sources, specifically in tests/reg-tests-2.R (lines 6574 ff), the new code now gives > ## error messages from (C-level) evalList > tst <- function(y) { stopifnot(is.numeric(y)); y+ 1 } > try(tst()) Error in eval(cl.i, pfr) : argument "y" is missing, with no default whereas previously it gave Error in stopifnot(is.numeric(y)) : argument "y" is missing, with no default But I think...

...t;> It currently breaks 'make check' in the R sources, > >>> >> specifically in tests/reg-tests-2.R (lines 6574 ff), > >>> >> the new code now gives > >>> >> > >>> >> > ## error messages from (C-level) evalList > >>> >> > tst <- function(y) { stopifnot(is.numeric(y)); y+ 1 } > >>> >> > try(tst()) > >>> >> Error in eval(cl.i, pfr) : argument "y" is missing, with no default > >>> >> > >>> &g...

I see in the archives that the attachment cannot pass. So, here is the code: 8<---- stopifnot_new <- function (...) { mc <- match.call() n <- length(mc)-1 if (n == 0L) return(invisible()) Dparse <- function(call, cutoff = 60L) { ch <- deparse(call, width.cutoff = cutoff) if (length(ch) > 1L) paste(ch[1L],