-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Futures: Parallel random number generation (RNG) #60
Comments
I like the attribute for the |
This is something the developer should control in their code. I don't think it should be modifiable by the end-user via an option - that'll give different results depending on option, which probably is not what the developer intended. |
I see the distinction. If the user is calling |
One can pass the
See:
So developers can utilize this behaviour to set the future seed. |
Signed-off-by: Peter Solymos <psolymos@gmail.com>
Good point. Yes, that looks like the cleanest solution. Then a rule of thumb can be to "pass any additional arguments to y <- pblapply(1:2, FUN = my_fcn, {additional my_fcn args}, cl = "future", {additional future args}) |
To prevent non-sound random numbers being produced when running in parallel, futureverse asks the developer to specify when their code needs the RNG. If not asked for, it'll still check to see if the RNG was used (i.e.
.Random.seed
) was updated. If it was, then a warning is produced.Here is an example:
To avoid this, a quick fix is for you could always pass
future.seed = TRUE
. That will set up a parallel RNG regardless of random numbers being generated or not. The downside is that it can be computationally expensive to do so. To give the developer the control, you'd have to introduce a new argument allowing the to control thefuture.seed
argument tofuture_lapply()
and likes. One way to do that without adding a new argument could be via attributes, e.g.The text was updated successfully, but these errors were encountered: