similar to: cwilcox - new version

I?ve been looking at this for a couple hours--it ended up being trickier than I expected to implement well. I?ve attached a new patch here. This version scales significantly better than the existing method for both `pwilcox` and `dwilcox`. Examples are included below. I can?t think of any other ways to improve runtime at this point. That?s not to say there aren?t any, though?I?m hopeful

Dear List, I'm writing to gauge interest in new syntax for positional-only function parameters to be added to R. The pattern of functions accepting other functions as inputs and passing additional ... arguments to them is prevalent throughout the R ecosystem. Currently, however, all such functions must one way or another tackle the problem of inadvertently passing arguments meant to go to

Hello Aidan, Sorry for dropping this for a while. ? Thu, 2 Mar 2023 21:03:59 +0000 "Lakshman, Aidan H" <AHL27 at pitt.edu> ?????: > //after > curnode = eval(lang3(R_Bracket2Symbol, parent->node, DEND_IND), env); lang3() always constructs a new language object. If you do end up using eval(), it may make sense to move lang3() out of the loop and reuse the existing object

> > > Performance statistics are interesting. If we assume the two populations > have a total of `m` members, then this implementation runs slightly slower > for m < 20, and much slower for 50 < m < 100. However, this implementation > works significantly *faster* for m > 200. The breakpoint is precisely when > each population has a size of 50; `qwilcox(0.5,50,50)`

tl;dr: R_CheckUserInterrupt() can be a performance bottleneck within GUIs. This also affects functions in the 'stats' package, which could be improved by changing the position of calls to R_CheckUserInterrupt(). Dear all, Recently I was puzzled because some code in a package under development, which consisted almost entirely of a .Call() to a function written in

A more generic solution would be for R to throttle calls to R_CheckUserInterrupt(), because it makes no sense to check 1000 times per second if a user has interrupted, but it is difficult for the caller to know when R_CheckUserInterrupt() has been last called, or do it regularly without over-doing it. Here is a simple patch: https://github.com/r-devel/r-svn/pull/125 See also:

This seems like a great idea. Would it help to escalate this to a post on R-bugzilla, so it is less likely to fall through the cracks? On 12/17/24 09:51, Jeroen Ooms wrote: > A more generic solution would be for R to throttle calls to > R_CheckUserInterrupt(), because it makes no sense to check 1000 times > per second if a user has interrupted, but it is difficult for the > caller to

It seems benign, but has implications since checking time is actually not a cheap operation: adding jus ta time check alone incurs a penalty of ca. 700% compared with the time it takes to call R_CheckUserInterrupt(). Generally, it makes no sense to check interrupts at every iteration - you'll find code like if (++i % 10000 == 0) R_CheckUserInterrupt(); in loops to make sure it's not called

On 12/18/24 01:19, Simon Urbanek wrote: > It seems benign, but has implications since checking time is actually not a cheap operation: adding jus ta time check alone incurs a penalty of ca. 700% compared with the time it takes to call R_CheckUserInterrupt(). Generally, it makes no sense to check interrupts at every iteration - you'll find code like if (++i % 10000 == 0)

? Sat, 15 Jun 2024 02:04:31 +0000 "Therneau, Terry M., Ph.D. via R-devel" <r-devel at r-project.org> ?????: > other attached packages: > [1] lme4_1.1-35.1 Matrix_1.7-0 I see you have a new Matrix (1.7-0 from 2024-04-26 with a new ABI) but an older lme4 (1.1-35.1 from 2023-11-05). I reproduced the crash and the giant backtrace by first installing latest lme4 and then

I did a quick test on one of my lab clusters with no tuning except for quota being enabled: [root at dell-per730-03 ~]# gluster v info Volume Name: vmstore Type: Replicate Volume ID: 0d2e4c49-334b-47c9-8e72-86a4c040a7bd Status: Started Snapshot Count: 0 Number of Bricks: 1 x (2 + 1) = 3 Transport-type: tcp Bricks: Brick1: 192.168.50.1:/rhgs/brick1/vmstore Brick2:

Hi, I have a gluster 3.10 volume with a dir with ~1 million small files in them, say mounted at /mnt/dir with FUSE, and I'm observing something weird: When I list and stat them all using rsync, then the lstat() calls that rsync does are incredibly fast (23 microseconds per call on average, definitely faster than a network roundtrip between my 3-machine bricks connected via Ethernet). But