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

Displaying 20 results from an estimated 3000 matches similar to: "Optimization bug when byte compiling with gcc 5.2.0 on windows"

2015 Sep 14
2
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
2015 Sep 14
0
Optimization bug when byte compiling with gcc 5.2.0 on windows
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
2015 Sep 14
1
Optimization bug when byte compiling with gcc 5.2.0 on windows
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
2016 Apr 04
5
Optimization bug when byte compiling with gcc 5.3.0 on windows
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
2007 Feb 23
1
how to use apply with two variables
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)
2010 Jun 29
1
Sweave, xtable plus/minus sign
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],
2010 Jun 23
2
About normality tests...
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
2007 Jul 07
1
calculating p-values of columns in a dataframe
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)
2012 Jan 06
1
Assign and cmpfun
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) {
2019 Jan 03
2
Compiler + stopifnot bug
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
2019 Jan 04
2
Compiler + stopifnot bug
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<-` <-
2005 Apr 27
1
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
2016 Nov 11
2
Frames in compiled functions
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 ##
2019 Jan 04
2
Compiler + stopifnot bug
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
2008 Sep 25
0
sd() of column, but for a subset of rows
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),
2017 Jun 14
2
[WISH / PATCH] possibility to split string literals across multiple lines
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
2019 Mar 31
3
stopifnot
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
2012 Dec 04
1
julia language unfair comparisons against R
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
2017 Apr 26
4
byte-compiler bug
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
2017 Oct 27
1
Slow down using the compiler
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