similar to: Proposed speedup of ifelse

> 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

Hugh, (Note I speak for myself only and not for R-core) Thanks for looking into this. I think it's great to have community members that are interested in contributing to R and helping it continue to get better. And I think, and my local experiments bear out, that using anyNA as a fastpass condition does allow us to get a significant speedup over what's in there now. To do so, though, I

Thanks Radford. I concur with all your points. I've attempted to address the issues you raised through the github.io post. The new method appears to be slower for test lengths < 100 and possibly longer lengths (not just < 10). Of course length(test) < 100 is very quick, so I simply added this to the conditions that cause the old ifelse method to be invoked. I'll leave it to

>>>>> Martin Maechler >>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >>>>> Hugh Parsonage >>>>> on Tue, 8 Sep 2020 18:08:11 +1000 writes: >> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): >> $> R --vanilla >> x <- c(0L, -2e9:2e9) >> # > Segmentation

I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): $> R --vanilla x <- c(0L, -2e9:2e9) # > Segmentation fault Tried to reproduce on Linux but the above worked as expected. Not an issue merely with the length of the vector; for example, x <- rep_len(1:10, 1e10) works, though the altrep vector must be long to reproduce: x <- c(0L, -1e9:1e9) #ok Segmentation

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

Hi, i need to use pspline. In this pspline function coxph.wtest was used. When I try to make some change to this function by pulling out the pspline function, it turns out R gave me an error msg, saying coxph.wtest cannot be found. Even if i dont change anything in pspline and just rename it and run the function, it did not work out. Can any one help me with this? is there anyway to get the

I write to clarify the status of \U and \L when used in the replacement argument to gsub in R 3.5.0. The behaviour of gsub appears to have changed from R 3.4.0, but the documentation for the replacement argument has not. ## Reprex (A call to readLines is essential. A url is provided for convenience but the behaviour should reproduce for local files) bib <- readLines("

Hello, I use t.test for normal distributed and wilcox.test for non-normal distributed samples. It is easy to write a function for t.test that calculates the effect size, because all parts of the formula are available from the t.test result: r = sqrt(t*t / (t*t + df)) However, for Wilcoxon tests, the formula for effect sizes is: r = Z / sqrt(N) I wonder how I can calculate the Z-score in R for

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

Inside of the anyNA() function, it will use the legacy any(is.na()) code if x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(), but it is also TYPEOF(x) == REALSXP. Therefore, it will skip the faster ITERATE_BY_REGION, which is typically 5x faster in my testing. Is the OBJECT() condition really necessary, or could it be moved after the switch() for the individual TYPEOF(x)

Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently memory usage of FLAC decoding is about 1MB, so this patch is increasing memory usage tenfold, also for platforms that do not need this. It is a non-problem on my system anyway. Op 26-09-14 om 10:36 schreef Janne Hyv?rinen: > I made some changes to the previous patch. I don't know why I > originally didn't put the

On 9/8/20 4:48 PM, Hugh Parsonage wrote: > Unfortunately I only get > > [Thread 21752.0x4aa8 exited with code 3221225477] > [Thread 21752.0x4514 exited with code 3221225477] > [Thread 21752.0x3f10 exited with code 3221225477] > [Inferior 1 (process 21752) exited with code 030000000005] > > (I'm guessing I would need to build an instrumented version of R, or > can R

hello everybody I use the following code for my programming & it runs with the error as specified below.Any help that would disolve the error will be highly appreciated. Thanks in advance my code looks like this #### R programme for simulating the power of the two sample t test vs various #### non-parametric alternatives sim.size <- 200 sample.size <- 10 set.seed(231) mu1 <- 0 delta

Hi, is there a hasNA() / an anyNA() function in R? Of course, hasNA <- function(x) { any(is.na(x)); } would do, but that would scan all elements in 'x' and then do the test. I'm looking for a more efficient implementation that returns TRUE at the first NA, e.g. hasNA <- function(x) { for (kk in seq(along=x)) { if (is.na(x[kk])) return(TRUE); } FALSE; }

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

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

Thanks for the quick responses. As you both suggested storing the packages to local drive is feasible but comes with a size restriction I wanted to avoid. I'll keep this in mind as plan B. @Hugh: 2. would impose even greater slowdowns and 4. is just not feasible. However, 3. sounds interesting - how would this work in a Linux environment? Thank you, Mario Am So., 19. Juli 2020 um 20:11 Uhr

On 9/9/20 9:30 AM, Hugh Parsonage wrote: > Thank you! > > I get > > Starting program: C:\R\R-devel-20200909\bin\x64\Rgui.exe > [New Thread 19940.0x638c] > [New Thread 19940.0x102c] > [New Thread 19940.0x329c] > [New Thread 19940.0x37dc] > warning: Invalid parameter passed to C runtime function. > > Program received signal SIGSEGV, Segmentation fault. >

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, times = ) has rep.int rep(x, length.out = ) has rep_len I think that a rep_each function would be a