similar to: `*tmp*`

Hello, I'm a bit puzzled by what looks (to me) like a discrepancy between documentation and implementation. The documentation for [] says this about the indices: "Numeric values are coerced to integer as by as.integer (and hence truncated towards zero)." > as.integer(-3.1) [1] -3 Good. But: > x <- c(1,2,3) > x[-3.1] [1] 1 2 3 Given the documentation, I'd have

Dear all, at UseR! 2013, the FastR project was announced by Tomas Kalibera, Petr Maj, and Jan Vitek. FastR is an implementation of the R programming language in Java using AST interpretation and specialisation for improved performance. Since, the implementation has been extended to support JIT compilation, leading to performance improvements. The goal of the project is to further the R community

Dear all, in R 3.1.0, this is happening: > cummin(c(1+1i,2-3i,4+5i)) Error in cummin(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 'cummax' not defined for complex numbers > cummax(c(1+1i,2-3i,4+5i)) Error in cummax(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 'cummin' not defined for complex numbers It may be fixed in R-devel, but I thought I'd mention it to make sure

Dear all, we are offering an internship position at Oracle Labs, in Redwood Shores (CA) or Potsdam (Germany). An outline of the job description can be found below. Additional details can be found at https://irecruitment.oracle.com (search for IRC2419637). Best regards, Michael Haupt "In the context of the Alphabet Soup project, Oracle Labs is contributing to an open-source optimised

Dear List, section "6.3 Random number generation" of WRE [1] lists unif_rand(), norm_rand() and exp_rand() as the interface to R's RNG. Now R_ext/Random.h also has double R_unif_index(double); Can this be also treated as an official API function that may be called from a package? Thanks Ralf [1] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Random-numbers --

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

Thanks for the reports. Will look into it soon and report back. Luke Sent from my iPhone > On Jan 3, 2019, at 2:15 PM, Martin Morgan <mtmorgan.bioc at gmail.com> wrote: > > For what it's worth this also introduced > >> df = data.frame(v = package_version("1.2")) >> rbind(df, df)$v > [[1]] > [1] 1 2 > > [[2]] > [1] 1 2

Luke, Thank you for sharing the benchmark results. The improvement is very substantial, I am looking forward to the release of the byte compiler! The arithmetic shows that x[i]<- is still the bottleneck. I suspect that this is due to a very involved dispatching/search for the appropriate function on the C level. There might be significant gain if loops somehow cached the result of the initial

When building R-devel with gcc 5.2.0 (mingw-w64 v4) on Windows, make check fails reg-tests-1b.R at the following check: x <- c(1:2, NA) sx <- sd(x) !is.nan(sx) Here 'sx' 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

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 ##

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > I'm not convinced that how to make :: faster is the right question. If > you are finding foo::bar being called often enough to matter to your > overall performance then to me the question is: why are you calling > foo::bar more than once? Making :: a bit faster by making it a > primitive will remove

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

Hi all, When S4 methods are defined on base function (say, "match"), the function becomes a method with the body "base::match(x,y)". A call to such a function often spends more time doing "::" than in the function itself. I always assumed that "::" was a very low-level thing, but it turns out to be a plain old function defined in base/R/namespace.R. What

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

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

Gabe As mentioned on Twitter, I think the following behavior should be fixed as part of the upcoming changes: R.version.string ## [1] "R Under development (unstable) (2019-02-25 r76160)" .Machine$double.digits ## [1] 53 set.seed(123) RNGkind() ## [1] "Mersenne-Twister" "Inversion"??????? "Rejection" length(table(runif(1e6))) ## [1] 999863 I don't

Ah, with R 3.5.0 or R 3.4.2, but 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

Thank you Luke. That is why I don't use Rf_inherits but INHERITS which does not allocate, provided in the email body. I cannot do similarly for S4 classes, thus asking for some API for that. On Fri, Nov 1, 2019 at 5:56 PM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > On Fri, 1 Nov 2019, Jan Gorecki wrote: > > > Dear R developers, > > > > Motivated by

Hola, Tenía una versión anterior de R, la 2.10.1 en la cual podía cargar perfectamente el paquete "lme4". Actualicé la versión del R a 2.14.0 y aún volviendo a descargar la nueva versión del paquete mencionado cuando intento cargarlo me da el siguiente error : > library(lme4) Error: package ‘lme4’ is not installed for ''arch=i386'' Hay alguna solución para esto o

Thank you Luke for prompt reply. Is it possible then to request a new function to R C API "message" that would equivalent to R "message" function? Similarly as we now have C "warning" and C "error" functions. Best, Jan On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > On Sun, 15 Sep 2019, Jan Gorecki wrote: