similar to: RE: [R] when can we expect Prof Tierney's compiled R?

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

> -----Original Message----- > From: Prof Brian Ripley [mailto:ripley@stats.ox.ac.uk] > Sent: Wednesday, April 27, 2005 1:13 AM > To: Vadim Ogranovich > Cc: Luke Tierney; r-devel@stat.math.ethz.ch > Subject: Re: [Rd] RE: [R] when can we expect Prof Tierney's > compiled R? > > On Tue, 26 Apr 2005, Vadim Ogranovich wrote: > ... > > The arithmetic shows

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

I am excited to learn that Prof. Tierney is bringing to us compiled R. I would like to learn when it will be available. This information will be useful in scheduling some of my projects. Thanks. Jason Jason Liao, http://www.geocities.com/jg_liao Dept. of Biostatistics, http://www2.umdnj.edu/bmtrxweb University of Medicine and Dentistry of New Jersey 683 Hoes Lane West, Piscataway‚ NJ 08854

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

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

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

Ralf I don't doubt this is expected with the current implementation, I doubt the implementation is desirable. Suggesting to turn this to pbirthday(1e6, classes = 2^53) ## [1] 5.550956e-05 (which is still non-zero, but much less likely to cause confusion.) Best regards Kirill On 26.02.19 10:18, Ralf Stubner wrote: > Kirill, > > I think some level of collision is actually

Hello, given that `*tmp*` is removed after a replacement, how can code like this work? Is there some special handling for a variable named `*tmp*` when it comes to make element assignments? > x<-c(1,2) > x[1]<-42 > `*tmp*`[1]<-7 # I would expect this one to fail > `*tmp*` Error: object '*tmp*' not found Confused greetings, Michael -- Dr. Michael Haupt Principal

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

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

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

>>>>> luke-tierney >>>>> on Tue, 8 Sep 2020 09:42:43 -0500 (CDT) writes: > On Tue, 8 Sep 2020, Martin Maechler wrote: >>>>>>> Martin Maechler >>>>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >> >>>>>>> Hugh Parsonage >>>>>>> on Tue, 8 Sep 2020

Before the next release we really should to sort out the bias issue in sample() reported by Ottoboni and Stark in https://www.stat.berkeley.edu/~stark/Preprints/r-random-issues.pdf and filed aa a bug report by Duncan Murdoch at https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17494. Here are two examples of bad behavior through current R-devel: set.seed(123) m <- (2/5) * 2^32

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

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,...

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

On Tue, 8 Sep 2020, Hugh Parsonage wrote: > Thanks Martin. On further testing, it seems that the segmentation > fault can only occur when the amount of obtainable memory is > sufficiently high. On my machine (admittedly with other processes > running): > > $ R --vanilla --max-mem-size=30G -e "x <- c(0L, -2e9:2e9)" > Segmentation fault > > $ R --vanilla

On Mon, 21 Jan 2019, Martin Maechler wrote: >>>>>> Travers Ching >>>>>> on Tue, 15 Jan 2019 12:50:45 -0800 writes: > > > I have a toy alt-rep string package that generates > > randomly seeded strings. example: library(altstringisode) > > x <- altrandomStrings(1e8) head(x) [1] > >