similar to: Speeding up transpose

Looking for more ways to speed up R, I've found that large improvements are possible in the speed of "sum" and "prod" for long real vectors. Here is a little test with R version 2.11.1 on an Intel Linux system > a <- seq(0,1,length=1000) > system.time({for (i in 1:1000000) b <- sum(a)}) user system elapsed 4.800 0.010 4.817 > system.time({for (i

Regarding Tengfei Yin's post about an error trying to install "cluster" in 2.13.0, I have gotten an error with this package when trying to install the released version of 2.12.0. Here is the output on an Ubuntu Linux system: begin installing recommended package cluster * installing *source* package 'cluster' ... ** libs make[3]: Entering directory

I have a factor vector of subject races (Asian, Black, Hispanic, White; n=30) that I want to plot with a Cleveland dotplot or dotchart. I tried the following in R2.12.1 : > dotchart(table(school$Race)) Error in plot.xy(xy.coords(x, y), type = type, ...) : invalid plot type Using the same data set in R2.11.1 the operation succeeded (I tried several variations to be sure): >

I've been getting pqR to work on windows systems, and in the process have discovered various problems with R core versions of R and with Rtools. One is with the implementation of OpenMP in 64-bit Rtools. This problem is in Rtools215 and Rtools33, and presumably all the ones in between. You can see the problem with the following test program: #include <stdio.h> #include <omp.h>

The current R release candidate has a lack of protect bug (of very long standing) with respect to the R_print.na_string and R_print.na_string_noquote fields of the static R_print structure declared in Print.h. This shows up very occassionally as incorrect output from the following lines in reg-tests-2.R: x <- c("a", NA, "b") factor(x) factor(x, exclude="")

> I propose a patch to ifelse that leverages anyNA(test) to achieve an > improvement in performance. For a test vector of length 10, the change > nearly halves the time taken and for a test of length 1 million, there > is a tenfold increase in speed. Even for small vectors, the > distributions of timings between the old and the proposed ifelse do > not intersect. For smaller

> > The current R release candidate has a lack of protect bug > > (of very long standing) > > [ but not really reported, right ? ] It's "long standing" because it exists in versions of R going back many years. > but the R 3.2.1 release candidate probably really cannot be > touched now, with something non-trivial like this. > > We'd be

Hi, I'm just following your messages the overhead that the code for dealing with possible NA/NaN values brings. When I was setting up part of the matrixStats package, I've also though about this. I was thinking of having an additional logical argument 'hasNA'/'has.na' where you as a user can specify whether there is NA/NaN:s or not, allowing the code to avoid it or not.

> Radford Nea: > > So it may make more sense to move towards consistency in the > > permissive direction, rather than the restrictive direction. > > > That would mean allowing matrix(1,1,1) < (1:2), and maybe also things > > like matrix(1,2,2)+(1:8). > > Martin Maechler: > That is an interesting idea. Yes, in my view that would >

In testing pqR on Solaris SPARC systems, I have found two bugs that are also present in recent R Core versions. You can see the bugs and fixes at the following URLs: https://github.com/radfordneal/pqR/commit/739a4960a4d8f3a3b20cfc311518369576689f37 https://github.com/radfordneal/pqR/commit/339b7286c7b43dcc6b00e51515772f1d7dce7858 The first bug, in nls, is most likely to occur on a 64-bit

> Then the question would be if this test could be replaced with a new > argument to sample, e.g. expandSingle, which has TRUE as default for > backward compatibility, but FALSE if you dont want population to be > expanded to 1:population. It could certainly be useful in some cases, > but you still need to know about the expansion to use it. I think most > of these bugs

Gabriel Becker writes: AFAIK R does not automatically copy function arguments. R actually tries very hard to avoid copying while maintaining "pass by value" functionality. ... R only copies data when you modify an object, not when you simply pass it to a function. This is a bit misleading. R tries to avoid copying by maintaining a count of how many references there are to an

> ... with assignments inside of loops like this: > > reweight = function(iter, w, Q) { > for (i in 1:iter) { > wT = w * Q > } > } > ... before the RHS is executed, the LHS allocation would be added > to a small fixed length list of available space which is checked > before future allocations. If the same size is requested before the > next garbage

> On Wed, 14 Jun 2017, G?bor Cs?rdi wrote: > > > I like the idea of string literals, but the C/C++ way clearly does not > > work. The Python/Julia way might, i.e.: > > > > """this is a > > multi-line > > lineral""" > > luke-tierney at uiowa.edu: > This does look like a promising option; some more careful checking

Michael Lawrence (as last in long series of posters)... > Yes, it would bind the language object to the environment, like an > R-level promise (but "promise" of course refers specifically to just > _lazy_ evaluation). > > For the uqs() thing, expanding calls like that is somewhat orthogonal > to NSE. It would be nice in general to be able to write something like >

Gabor Csardi writes: > Btw. for some motivation, here is a (surely incomplete) list of > languages with '+' as the string concatenation operator: > > ALGOL 68, BASIC, C++, C#, Cobra, Pascal, Object Pascal, Eiffel, Go, > JavaScript, Java, Python, Turing, Ruby, Windows Powers hell, > Objective-C, F#, Sc-ala, Ya. The situation for R is rather different from that of a

> > But isn't the intent to make it an error later? So I assume we're > > debating making it an error, not just a warning. > > Yes, that's correct. > But if we have a longish deprecation period (i.e. where there's > only a warning) all important code should have been adapted > before it turns to an error That might be true for

> From: Martin Maechler <maechler at lynne.stat.math.ethz.ch> > diag() should not work only for pure matrices, but for all > "matrix-like" objects for which ``the usual methods'' work, such > as > as.vector(.), c(.) > > That's why there has been the c(.) in there. > > You can always make code faster if you write the code so it only >

> From: Richard Cotton <richierocks at gmail.com> > > The rep function is very versatile, but that versatility comes at a > cost: it takes a bit of effort to learn (and remember) its syntax. > This is a problem, since rep is one of the first functions many > beginners will come across. Of the three main uses of rep, two have > simpler alternatives. > > rep(x,

Regarding Martin Maechler's proposal: Arithmetic between length-1 arrays and longer non-arrays had silently dropped the array attributes and recycled. This now gives a warning and will signal an error in the future, as it has always for logic and comparison operations For example, matrix(1,1,1) + (1:2) would give a warning/error. I think this might be a mistake. The potential