similar to: Optimization bug when byte compiling with gcc 5.2.0 on windows

On 14/09/2015 9:36 AM, luke-tierney at uiowa.edu wrote: > I believe the issue is that on Windows the sqrt function when called > with a NaN does not return the same NaN, as it does on other platforms. > We have > > #if (defined(_WIN32) || defined(_WIN64)) && defined(__GNUC__) && \ > __GNUC__ <= 4 > # define R_sqrt(x) (ISNAN(x) ? x : sqrt(x)) > #else

I believe the issue is that on Windows the sqrt function when called with a NaN does not return the same NaN, as it does on other platforms. We have #if (defined(_WIN32) || defined(_WIN64)) && defined(__GNUC__) && \ __GNUC__ <= 4 # define R_sqrt(x) (ISNAN(x) ? x : sqrt(x)) #else # define R_sqrt sqrt #endif for implementing the SQRT opcode. I suspect this came from Duncan

On Mon, Sep 14, 2015 at 8:49 PM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote: > I tested this hypothesis by replacing '__GNUC__ <= 4' with '__GNUC__ > <= 5' and rebuilding R, but this introduces a whole lot of problems > that were not there before. In particular R crashes when using the > graphics device, which it did not without this fix. I found

Hi, Apologies for breaking the threading on this, I've only just signed up to the list and the last email was from September 2015. I've started to look into building R for Windows using MSYS2 as both the build environment and tools + libraries provider (where possible). I've managed to get the testsuite to pass on a recent MSYS2 MinGW-w64 x86-64 GCC: gcc.exe (Rev1, Built by MSYS2

Hi, this is a made-up example. Function "myfun" returns two arguments. Can "apply" be used so that "myfun" is called only once? Thanks Serguei mat<-matrix(runif(50),nrow=10,ncol=5) myfun<-function(x) { mymean<-mean(x) mysd<-sd(x) return(mymean,mysd) } out1<-t(apply(mat,1,function(x) myfun(x)$mymean)) out2<-t(apply(mat,1,function(x)

Dear R-users, please consider the following minimal example: \documentclass[a4paper,titlepage,onecolumn,12pt]{article} \usepackage[italian]{babel} \usepackage{amssymb} \usepackage[utf8x]{inputenc} \usepackage[pdftex]{graphicx} \begin{document} <<label=test, echo=FALSE, results=tex>>= df.data1 <- cbind.data.frame(A = rnorm(18), B =factor(rep(LETTERS[1:6],

Hi all, I have two very large samples of data (10000+ data points) and would like to perform normality tests on it. I know that p < .05 means that a data set is considered as not normal with any of the two tests. I am also aware that large samples tend to lead more likely to normal results (Andy Field, 2005). I have a few questions to ensure that I am using them right. 1) The Shapiro-Wilk

I have a dataframe ("mydf") that contains "differences of means". I wish to test whether these differences are significantly different from zero. Below, I calculate the t-statistic for each column. What is a "good" method to calculate/look-up the p-value for each column? mydf=data.frame(a=c(1,-22,3,-4),b=c(5,-6,-7,9)) mymean=mean(mydf) mysd=sd(mydf)

Hi All, I've just recently discovered the cmpfun function, and was wanting to to create a function to assign this to all the functions i have created, but without explicitly naming them. I've achieved this with: foo <- function(x) { print(x)} bar <- function(x) { print(x + 1)} > foo <- function(x) { print(x)} > foo function(x) { print(x)} > cmpfun(foo) function(x) {

Hi, I found the following issue in r-devel (2019-01-02 r75945): `foo<-` <- function(x, value) { bar(x) <- value * x x } `bar<-` <- function(x, value) { stopifnot(all(value / x == 1)) x + value } `foo<-` <- compiler::cmpfun(`foo<-`) `bar<-` <- compiler::cmpfun(`bar<-`) x <- c(2, 2) foo(x) <- 1 x # should be c(4, 4) #> [1] 3 3 If the functions

On 03/01/2019 3:37 p.m., Duncan Murdoch wrote: > I see this too; by bisection, it seems to have first appeared in r72943. Sorry, that was a typo. I meant r75943. Duncan Murdoch > > Duncan Murdoch > > On 03/01/2019 2:18 p.m., I?aki Ucar wrote: >> Hi, >> >> I found the following issue in r-devel (2019-01-02 r75945): >> >> `foo<-` <-

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

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

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 Tue, Feb 13, 2018 at 12:22 PM, Indrajit Sen Gupta <indrajitsg at gmail.com> wrote: > Hi Avraham, > > I tried with the patched version. The same error message. > > gcc -std=gnu99 -m64 -shared -s -mwindows -o R.dll R.def console.o dynload.o > editor.o embeddedR.o extra.o malloc.o opt.o pager.o preferences.o psignal.o > rhome.o rt_complete.o rui.o run.o shext.o

I would like to take the standard deviation of a column, but only for a subset of the rows in that column with a given index. The following loop worked fine when I wanted the mean, but is not working for the standard deviation: for (i in 1:length(x[1,])){ a<-tapply(x[,i],x[,2],sd, na.rm=TRUE) xnew<-cbind(xnew,a)} I have tried re-defining the sd as follows (as suggested on this board),

Mark, that's actually a fair statement, although your extra operator doesn't cause construction at parse time. You still call paste0(), but just add an extra layer on top of it. I also doubt that even in gigantic loops the benefit is going to be significant. Take following example: atestfun <- function(x){ y <- paste0("a very long", "string for

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

Hello List, Probably many of you aware of the Julia language (http://julialang.org/), It is a promising project. However it seems like R is very slow in their benchmarks. Very important point they omit, they did not use R's own JIT ! I had a feeling that R is mistreaded there :) Also another important point is that they all use for-loops in R instead of vectorized code! Any thought on

I think that this is because `[<-` dispatches on S4 methods only if the first argument is S4. ?"[<-" says: "These operators are also implicit S4 generics, but as primitives, S4 methods will be dispatched only on S4 objects ?x?." Georgi Boshnakov -----Original Message----- Message: 19 Date: Tue, 8 Sep 2020 22:04:44 -0400 From: Ben Bolker <bbolker at