About a best practice vignette

[pat-s]

@HenrikBengtsson and I were discussing the optimal use of {doRNG} within the {future} framework in futureverse/doFuture#41.

The discussion started after I posted a blog post about reproducible parallel streams in R.

We've been discussing which way of the following is better to recommend/use longterm

• using the %dorng% operator
• using doRNG::registerDoRNG() with %dopar%

Maybe you can give some insights from the dev perspective. These could potentially be added to the README/vignette of this package.

[renozao]

I guess we could say the following: * doRNG::registerDoRNG() with %dopar% : global setting for setup and forget, assuming the workflow does not change backend in the middle. * %dorng% is for once of usage, that allows selecting which foreach loop get to use RNG streams, to limit interference. Kind of a shortcut for Add doRNG layer -> foreach %dopar% -> remove doRNG layer

[HenrikBengtsson]

Thanks for your input on this. So, I initially agreed with you but lately, I think developers should use the explicit %dorng%. My rationale is that it is only with %dorng% that you as the developer can be sure that the algorithm you develop uses a valid RNG stream. With doRNG::registerDoRNG() and %dopar% we put that burden on the end-user and we cannot demand that they should know what is needed, especially not if our foreach() code is part of a package far down the dependency tree. Because of this, I'd even argue that not using %dorng% is incorrect/a bug.

If parallel RNG end up being handled upstream by foreach() (RevolutionAnalytics/foreach#6), then I can imagine that one can replace the %dorng%-wrapper "hack" with a formal argument, e.g. y <- foreach(..., rng = TRUE) %dopar% { ... }. That way the developer has full control of parallel RNGs. One can imagine support for alternative parallel RNGs via this argument too, e.g. rng = "L'Ecuyer-CMRG", rng = list(<seeds>), etc. but the exact design of that is better discussed in RevolutionAnalytics/foreach#6.