[Rd] Language definition question - order of argument side effects

", but doesn't say anything about evaluation order. In general, for primitive and internal functions, is a particular evaluation order for the arguments guaranteed? Thanks, Justin Talbot __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] pmatch inconsistency

The pmatch help (see also section 4.3.2 in the R Language Definition) claims that pmatch with duplicates.ok=FALSE provides the same functionality as R's argument matching algorithm, modulo how empty strings are matched. Here's an undocumented inconsistency between pmatch and R's argument matching

[Rd] Multiple return values / bug in rpart?

artpl.R is used anywhere, so this may have never caused an issue. But it's tripping up my R compiler. Thanks, Justin Talbot __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Status of reserved keywords and builtins

e language functions and are found via the global environment at compile time may be inlined." This is an area where a small change to the language spec would impact essentially no users and would result in a language that could be executed much more efficiently. Justin Talbot ___

[Rd] On R performance

I've been working on an R performance academic project for the last couple years which has involved writing an interpreter for R from scratch and a JIT for R vector operations. With the recent comments on Julia, I thought I'd share some thoughts from my experience since they differ substantially f

Re: [Rd] On R performance

> > On 8 March 2012 at 11:06, Justin Talbot wrote: > | I've been working on an R performance academic project for the last > | couple years which has involved writing an interpreter for R from > | scratch and a JIT for R vector operations. > > Cool.  I think John mentio

Re: [Rd] On R performance

> > Isn't R much like Lisp under the covers? Afterall, it evolved from Scheme. > Hasn't there been a great deal of work done on optimizing Lisp over the > last 30 years? This suggests that instead of dropping the R/S semantics > and moving to another language like Julia, the proposals of Ross Ihaka

Re: [Rd] On R performance

> > Thanks for the clarification Justin. What about the S4 classes > and methods? The design resembles CLOS, and currently this > is interpreted R code. Have you addressed performance issues > associated with this? What relative impact does this have compared > with other optimizations like vectori

Re: [Rd] There is pmin and pmax each taking na.rm, how about psum?

> Because that's inconsistent with pmin and pmax when two NAs are summed. > > x = c(1,3,NA,NA,5) > y = c(2,NA,4,NA,1) > colSums(rbind(x, y), na.rm = TRUE) > [1] 3 3 4 0 6# actual > [1] 3 3 4 NA 6 # desired But your desired result would be inconsistent with sum: sum(NA,NA,na.rm=TRUE) [1] 0 >

Re: [Rd] There is pmin and pmax each taking na.rm, how about psum?

> > Then the case for psum is more for convenience and speed -vs- > colSums(rbind(x,y), na.rm=TRUE)), since rbind will copy x and y into a new > matrix. The case for pprod is similar, plus colProds doesn't exist. > Right, and consistency; for what that's worth. >> Thus, + should have the signatur

[Rd] Bug in list subset assignment due to NAMED optimization

In R version 2.15.2 (2012-10-26) i386-apple-darwin9.8.0/i386 (32-bit) I get the following: > a <- list(1) > (a[[1]] <- a) [[1]] [[1]][[1]] [1] 1 but > a <- list(1) > b <- a > (a[[1]] <- a) [[1]] [1] 1 And similarly: > a <- list(x=1) > (a$x <- a) $x $x$x [1] 1 but > a <- list(x=1) > b <- a >