Hi Steffi,
This solution looks fine to me. One thing the man page for my_func should make
really clear is that calling
my_func(..., seed=123)
is not necessarily equivalent to doing
set.seed(123)
my_func(...)
but only the former is guaranteed to be deterministic no matter what.
I
It seems to me that BiocParallel should not touch the parallel stream at
load. I don't see why that is necessary, but ok, I just have a vague
understanding of why its doing it, so perhaps I am wrong.
On Thu, May 23, 2019 at 4:29 AM Steffi Grote
wrote:
> Thank you Martin, that's exactly the probl
Thank you Martin, that's exactly the problem.
So for now I will just leave it like it is without setting a seed inside a
function,
and hope that the behaviour of DelayedArray might be updated. Anyway, I don't
think it is a big problem.
Best,
Steffi
> On May 22, 2019 at 5:02 PM Martin Morgan wr
I think the problem is that, even if the user were to set.seed(), it will have
different consequences depending on whether DelayedArray is already loaded, or
not yet loaded. DelayedArray gets loaded in some way that is not transparent to
the user, as a dependency-of-a-dependency-of-an annotation
Why don't you let this be under the user's control and not do this at all.
People should know that reproducibility of random numbers requires setting
the seed, but that is best done by the user and not a package author.
On Wed, May 22, 2019 at 9:30 AM Steffi Grote
wrote:
> Hi all,
>
> I tried to
Hi all,
I tried to circumvent the problem by adding an optional seed as parameter like
this:
my_fun = function(..., seed = NULL){
code that might change the RNG
if (!is.null(seed)){
set.seed(seed)
}
code that runs permutations
}
which solves the reproducibi
Hi Martin and Herve,
thanks for the quick responses and the clarification.
It's not an issue now that I know this happens, and can just load DelayedArray
outside of the function.
Best,
Steffi
> On April 12, 2019 at 1:10 AM Martin Morgan wrote:
>
>
> That easy strategy wouldn't work, for inst
That easy strategy wouldn't work, for instance two successive calls to
MulticoreParam() would get the same port assigned, rather than the contract of
a 'random' port in a specific range; the port can be assigned by the
manager.port= argument if the user wants to avoid random assignment. I could
Hi Steffi,
Any code that gets called between your calls to set.seed() and runif()
could potentially use the random number generator. So the sequence
set.seed(123); runif(1) is only guaranteed to be deterministic if no
other code is called in between, or if the code called in between does
not u
This is actually from a dependency DelayedArray which, on load, calls
DelayedArray::setAutoBPPARAM, which calls BiocParallel::MulticoreParam(), which
uses the random number generator to select a random port for connection.
A different approach would be for DelayedArray to respect the user's
con
Hi all,
I found out that example code for my package GOfuncR yields a different result
the first time it's executed, despite setting a seed. All the following
executions are identical.
It turned out that loading the database package 'Homo.sapiens' changed the
random numbers:
set.seed(123)
runif
11 matches
Mail list logo
