similar to: loop compilation problem

Hi, the functions in distn.R were converted from .Internal to .External ([1], in 2012), and to .Call ([2], in 2014). They are still listed as .Internal in names.c, although they are not used in that way. Shouldn?t they be removed? There?s quite some simplification to be had, e.g., do_math3 could go away and do_math2 would be simpler. If that makes sense (I may be missing something?), I?d be

Hello, Due to exploration of the JIT capabilities offered through the {compiler} package, I came by the fact that using enableJIT(2) can *slow* the rpart function (from the {rpart} package) by a magnitude of about 10 times. Here is an example code to run: library(rpart) require(compiler) enableJIT(0) # just making sure that JIT is off # We could also use enableJIT(1) and it would be fine fo

Hi! I was wondering about the behavior of the range function wrt. logical NAs: > range(c(0L, 1L, NA), finite=T) [1] 0 1 > range(c(F, T, NA), finite=T) [1] NA NA The documentation is quite clear that "finite = TRUE includes na.rm = TRUE?, so that I would have assumed that these two snippets would produce the same result. - Lukas

Hi, I'm running into a case where byte-compilation changes the semantic of a function. This is with R 3.4.0: foo <- function(x) { TRUE && x } foo(c(a=FALSE)) # [1] FALSE # OK foo(c(a=TRUE)) # [1] TRUE # OK foo(c(a=FALSE)) # a # ???? # FALSE The 3rd call returned a result that it different from the 1st call! After

Hi, Browser doesn't work properly with the compiler enabled. It might be intended behavior, but it's not documented. compiler::enableJIT(1) foo <- function(){ browser() cat("here\n") } Browser doesn't stop, and I am getting: > foo() Called from: foo() Browse[1]> here > Thanks, Vitalie. > sessionInfo() R version 2.14.2 (2012-02-29) Platform:

I noticed some problems that cropped in the latest versions of R-devel (2016-11-08 r71639 in my case) for one of my 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 ##

I'm not sure if this is a bug or expected behavior, but I don't see anything in the documentation that explains it, so I thought I'd mention it: ~ michaelweylandt$ R -q --vanilla library(compiler) enableJIT(3) `+` # Throws an error `+` # Throws a warning `+` # Prints the primitive as expected sessionInfo() R version 2.14.1 (2011-12-22) Platform: i386-apple-darwin9.8.0/i386

?typeof? is your friend here: > typeof(`[`) [1] "special" > typeof(mc[[1]]) [1] "symbol" > typeof(mc2[[1]]) [1] "special" so mc[[1]] is a symbol, and thus not a primitive. - Lukas > On 28 Mar 2017, at 14:46, Michael Lawrence <lawrence.michael at gene.com> wrote: > > There is a difference between the symbol and the function (primitive >

In this email to the R-help list: https://stat.ethz.ch/pipermail/r-help/2017-June/447474.html and in this question on Stackoverflow: https://stackoverflow.com/questions/44486643/nleqslv-memory-use-in-r Andrew Leach has raised a question about the memory usage of my package nleqslv. In a model with a loop within a function he has experienced continuously increasing memory usage by package nleqslv

I hope you don?t mind us using this mailing list for a small advertisement, but we think it is most relevant for this group: We'd like to invite you to RIOT 2020 - the 5rd workshop on R Implementation, Optimization and Tooling [1]. It will take place co-located with, and during, useR! 2020 in St. Louis on July 8th. RIOT is an excellent venue for deep technical discussions about R

Hi, there was a change concerning logical operations about a year ago: https://github.com/wch/r-source/commit/9e19d3e3dd5f657b5cfefe562bdd7ede2e2b8786 It's related to a discussion on this list: https://hypatia.math.ethz.ch/pipermail/r-devel/2016-September/073068.html <https://hypatia.math.ethz.ch/pipermail/r-devel/2016-September/073068.html> A change in logic.c:134 influences the

The build system rolled up R-3.4.3.tar.gz (codename "Kite-Eating Tree") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.4.3.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard

The build system rolled up R-3.4.3.tar.gz (codename "Kite-Eating Tree") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.4.3.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard

I think there?s a bug concerning the formatting of raw vectors with names: > structure(as.raw(1:3), .Names = c("a", "bbbb", "c")) a bbbb c 01 02 03 > structure(1:3, .Names = c("a", "bbbb", "c")) a bbbb c 1 2 3 The problem is that EncodeRaw does not honor the requested width, in fact it doesn?t even get the

> .Internal(inspect(1:10)) @300e4e8 13 INTSXP g0c0 [NAM(3)] 1 : 10 (compact) > .Internal(inspect(seq(1,10))) @3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,... > system.time(1:1e7) user system elapsed 0 0 0 > system.time(seq(1,1e7)) user system elapsed 0.05 0.00 0.04 It seems that result of function 'seq' doesn't use compact

Hi! We?ve recently come across an example where a package (minqa) creates an Rcpp Function object in a static variable. This causes R_ReleaseObject to be called by the destructor at a very late point in time - as part of the system exit function: static Function cf("c"); I?m wondering if that is considered to be ?safe?? Is the R engine supposed to stay in a state where calls to API

A shorter reproducible example: example(makeActiveBinding) for (fred in 1:3) { 0 } ls() Both problems go away if you first do compiler::enableJIT(2) So looks like a bug in compiling the for loop. -Deepayan On Sat, May 23, 2020 at 5:45 PM Thomas Friedrichsmeier via R-devel <r-devel at r-project.org> wrote: > > Possibly just a symptom of the earlier behavior, but I'll amend my

Thanks -- I'll commit a fix after some testing. Best, luke On 04/29/2018 06:22 AM, Duncan Murdoch wrote: > On 28/04/2018 11:11 PM, Suharto Anggono Suharto Anggono via R-devel wrote: >>> .Internal(inspect(1:10)) >> @300e4e8 13 INTSXP g0c0 [NAM(3)]? 1 : 10 (compact) >>> .Internal(inspect(seq(1,10))) >> @3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,...

Dear All, In R 3.4.2 (Linux), the compiler seems to have regressed: $ R --vanilla g = function() { N = 1e7; ans = numeric(N) system.time({for (j in 1:N) ans[j] = 1}) } g() # user system elapsed # 4.272 0.000 4.272 g1 = compiler::cmpfun(g) g1() # user system elapsed # 4.232 0.004 4.235 Running the above code in Windows 3.3.1, g() takes the same time, but g1() takes around 0.5

Thanks: I installed from source and got an error when loading a package: -------------------------------------------------------------------- > library(eha) Loading required package: survival Error: package or namespace load failed for ?eha? in dyn.load(file, DLLpath = DLLpath, ...): unable to load shared object '/usr/local/lib/R/site-library/eha/libs/eha.so':