search for: cmpfun

Hi All, I've just recently discovered the cmpfun function, and was wanting to to create a function to assign this to all the functions i have created, but without explicitly naming them. I've achieved this with: foo <- function(x) { print(x)} bar <- function(x) { print(x + 1)} > foo <- function(x) { print(x)} > foo function(...

...x' should be 'NA' but it is 'NaN'. It turns out this problem only appears when the function is byte compiled with optimization level 3: mysd <- function (x, na.rm = FALSE) sqrt(var(if (is.vector(x)) x else as.double(x), na.rm = na.rm)) mysd(x) # [1] NA compiler::cmpfun(mysd, list(optimize = 1L))(x) # [1] NA compiler::cmpfun(mysd, list(optimize = 2L))(x) # [1] NA compiler::cmpfun(mysd, list(optimize = 3L))(x) # [1] NaN The problem does not appear with gcc 5.2.0 on Debian, and also not with gcc 4.9.3 on Windows. Where do I start debugging this? The disas...

Hi, I found the following issue in r-devel (2019-01-02 r75945): `foo<-` <- function(x, value) { bar(x) <- value * x x } `bar<-` <- function(x, value) { stopifnot(all(value / x == 1)) x + value } `foo<-` <- compiler::cmpfun(`foo<-`) `bar<-` <- compiler::cmpfun(`bar<-`) x <- c(2, 2) foo(x) <- 1 x # should be c(4, 4) #> [1] 3 3 If the functions are not compiled or the stopifnot call is removed, the snippet works correctly. So it seems that something is messing around with the references to "v...

...packages. I _think_ I have narrowed it down to the changes to what gets byte-compiled by default. The following example run illustrates the problem I'm having: compiler::enableJIT(0) fun <- function(x) local(as.list(parent.frame(2))) fun(1) ## $x ## [1] 1 ## compiler::cmpfun(fun)(1) ## <contents of .GlobalEnv> Is this considered problematic at all? If so, might it make sense to broaden the list of functions that disable JIT compilation beyond `browser`? I'm pretty sure I can work around this issue in my specific use case, but figured it is worth mention...

...): >> >> `foo<-` <- function(x, value) { >> bar(x) <- value * x >> x >> } >> >> `bar<-` <- function(x, value) { >> stopifnot(all(value / x == 1)) >> x + value >> } >> >> `foo<-` <- compiler::cmpfun(`foo<-`) >> `bar<-` <- compiler::cmpfun(`bar<-`) >> >> x <- c(2, 2) >> foo(x) <- 1 >> x # should be c(4, 4) >> #> [1] 3 3 >> >> If the functions are not compiled or the stopifnot call is removed, >> the snippet works correct...

...r (i in iA) x[i-1] > f3 <- function(x, iA) for (i in iA) 1 > f4 <- function(x, iA) for (i in iA) x[i] = 1.0 > f5 <- function(x, iA) for (i in iA) i-1 > f6 <- function(x, iA) for (i in iA) i > > Make byte compiled versions: > > f1c <- cmpfun(f1) > f2c <- cmpfun(f2) > f3c <- cmpfun(f3) > f4c <- cmpfun(f4) > f5c <- cmpfun(f5) > f6c <- cmpfun(f6) > > and run them: > > > system.time(f1(x, iA)) > [1] 5.43 0.04 5.56 0.00 0.00 > > system.time(f1c(x...

...function(x, value) { >>> bar(x) <- value * x >>> x >>> } >>> >>> `bar<-` <- function(x, value) { >>> stopifnot(all(value / x == 1)) >>> x + value >>> } >>> >>> `foo<-` <- compiler::cmpfun(`foo<-`) >>> `bar<-` <- compiler::cmpfun(`bar<-`) >>> >>> x <- c(2, 2) >>> foo(x) <- 1 >>> x # should be c(4, 4) >>> #> [1] 3 3 >>> >>> If the functions are not compiled or the stopifnot call is removed,...

With f <- function(x) for (i in 1) x fc <- cmpfun(f) (my previous example), error message of fc(is.numeric(y)) shows the originating call as well, while error message of f(is.numeric(y)) doesn't. Compiled version behaves differently. Even with f <- function(x) for (i in 1) {x; eval(expression(i))} fc <- cmpfun(f) , error message of fc(i...

...s 'NaN'. It turns out this problem > only appears when the function is byte compiled with optimization > level 3: > > mysd <- function (x, na.rm = FALSE) > sqrt(var(if (is.vector(x)) x else as.double(x), na.rm = na.rm)) > > mysd(x) > # [1] NA > compiler::cmpfun(mysd, list(optimize = 1L))(x) > # [1] NA > compiler::cmpfun(mysd, list(optimize = 2L))(x) > # [1] NA > compiler::cmpfun(mysd, list(optimize = 3L))(x) > # [1] NaN > > The problem does not appear with gcc 5.2.0 on Debian, and also not > with gcc 4.9.3 on Windows. Where do...

...1) ## [[1]] ## fun(1) ## ## [[2]] ## local(sys.calls()) ## ## [[3]] ## eval.parent(substitute(eval(quote(expr), envir))) ## ## [[4]] ## eval(expr, p) ## ## [[5]] ## eval(expr, envir, enclos) ## call ## [[6]] ## eval(quote(sys.calls()), new.env()) ## ## [[7]] ## eval(expr, envir, enclos) compiler::cmpfun(fun)(1) ## [[1]] ## (compiler::cmpfun(fun))(1) ## ## [[2]] ## (function() sys.calls())() -Winston On Fri, Nov 11, 2016 at 1:13 PM, brodie gaslam via R-devel < r-devel at r-project.org> wrote: > I noticed some problems that cropped in the latest versions of R-devel > (2016-11-08 r71...

If we are on the subject of byte compilation, let me bring a couple of examples which have been puzzling me for some time. I'd like to know a) if the compilation will likely to improve the performance for this type of computations, and b) at least roughly understand the reasons for the observed numbers, specifically why x[i]<- assignment is so much slower than x[i] extraction. The loops

...t; > only appears when the function is byte compiled with optimization > > level 3: > > > > mysd <- function (x, na.rm = FALSE) > > sqrt(var(if (is.vector(x)) x else as.double(x), na.rm = na.rm)) > > > > mysd(x) > > # [1] NA > > compiler::cmpfun(mysd, list(optimize = 1L))(x) > > # [1] NA > > compiler::cmpfun(mysd, list(optimize = 2L))(x) > > # [1] NA > > compiler::cmpfun(mysd, list(optimize = 3L))(x) > > # [1] NaN > > > > The problem does not appear with gcc 5.2.0 on Debian, and also not >...

Hi I'm trying to set up a simulation problem without resorting to (m)any loops. I want to set entries in a data frame of zeros ('starts' in the code below) to 1 at certain points and the points have been randomly generated and stored in a separate data.frame ('sl'), which has the same number of columns. An example of the procedure is as follows: ml <-

...s the benefit is going to be significant. Take following example: atestfun <- function(x){ y <- paste0("a very long", "string for testing") grep(x, y) } atestfun2 <- function(x){ y <- "a very long string for testing" grep(x,y) } cfun <- cmpfun(atestfun) cfun2 <- cmpfun(atestfun2) require(rbenchmark) benchmark(atestfun("a"), atestfun2("a"), cfun("a"), cfun2("a"), replications = 100000) Which gives after 100,000 replications: test replications...

Dear All, I regularly want to "apply" some function to an array in a way that the arguments to the user function depend on the index on which the apply is working. A simple example is: A <- array( runif(160), dim=c(5,4,8) ) x <- matrix( runif(32), nrow=4, ncol=8 ) b <- runif(8) f1 <- function( A, x, b ) { sum( A %*% x ) + b } result <- rep(0.0,8) for (i in 1:8) {

...not with R 3.3.1, 'eval' inside 'for' makes compiled version behave like non-compiled version. options(error = expression(NULL)) library(compiler) enableJIT(0) f <- function(x) for (i in 1) {x; eval(expression(i))} f(is.numeric(y)) # Error: object 'y' not found fc <- cmpfun(f) fc(is.numeric(y)) # Error: object 'y' not found Is this accidental feature going to be relied upon? "Details" section of 'stopifnot' documentation in current R 3.6.0 alpha (https://svn.r-project.org/R/branches/R-3-6-branch/src/library/base/man/stopifnot.Rd) has this....

...imes, the function is not byte-compiled so is behaving as expected. 2) However after the 2nd call, the function gets automatically compiled. This seems to be a new feature in R 3.4.0 but you'll have to grep the NEWS file to find out (search for JIT). The man page for cmpfun/enableJIT nicely explains the JIT levels but I couldn't find anywhere that the level is set to 3 by default. I don't even know how one is supposed to get the current level. Calling enableJIT() to change the level returns a value, and this value might look like...

...nction(x, value) { >> bar(x) <- value * x >> x >> } >> >> `bar<-` <- function(x, value) { >> stopifnot(all(value / x == 1)) >> x + value >> } >> >> `foo<-` <- compiler::cmpfun(`foo<-`) >> `bar<-` <- compiler::cmpfun(`bar<-`) >> >> x <- c(2, 2) >> foo(x) <- 1 >> x # should be c(4, 4) >> #> [1] 3 3 >> >> If the functions are not compiled or the stopifnot call is removed,...

...bar(x) <- value * x >>>> x >>>> } >>>> >>>> `bar<-` <- function(x, value) { >>>> stopifnot(all(value / x == 1)) >>>> x + value >>>> } >>>> >>>> `foo<-` <- compiler::cmpfun(`foo<-`) >>>> `bar<-` <- compiler::cmpfun(`bar<-`) >>>> >>>> x <- c(2, 2) >>>> foo(x) <- 1 >>>> x # should be c(4, 4) >>>> #> [1] 3 3 >>>> >>>> If the functions are not compiled or t...

...ant point they omit, they did not use R's own JIT ! I had a feeling that R is mistreaded there :) Also another important point is that they all use for-loops in R instead of vectorized code! Any thought on this? Are there any other improvement one can do with compiler package other then 'cmpfun'? Best, -m