Thanks for your answers. I agree with Duncan and Henrik that we should have 
such a policy, even if we cannot test it. 

> On 30. Oct 2019, at 17:59, Henrik Bengtsson <henrik.bengts...@gmail.com> 
> wrote:
> 
> Forgot to say: For,
> 
>  oseed <- base::getRandomSeed()
>  on.exit(base::setRandomSeed(oseed))
> 
> one could upgrade set.seed() to take this role, e.g.
> 
>  oseed <- set.seed(0xBEEF)
>  on.exit(set.seed(oseed))
> 
> Current, set.seed() always return NULL.
> 
> BTW, and my memory might be bad, I think I mentioned this in the past
> but was told that you cannot reset the RNG state for all types of RNG
> kinds.  That might complicate things, but on the other hand, that
> could be checked for at run-time by the above functions.
> 
> /Henrik
> 
> On Wed, Oct 30, 2019 at 9:50 AM Henrik Bengtsson
> <henrik.bengts...@gmail.com> wrote:
>> 
>>> On 30/10/2019 9:08 a.m., peter dalgaard wrote:
>>>> You can fairly easily work around that by saving and restoring 
>>>> .Random.seed.
>> 
>> This is actually quite tedious to get correct; it requires you to
>> under how and when .Random.seed is set, and what are valid values on
>> .Random.seed.   For instance, a common mistake (me too) is to reset to
>> .GlobalEnv$.Random.seed <- NULL in a fresh R session but this will
>> produce a warning on: ".Random.seed' is not an integer vector but of
>> type 'NULL', so ignored".  You end up having to do things such as:
>> 
>>  oseed <- .GlobalEnv$.Random.seed
>>  on.exit({
>>    if (is.null(oseed)) {
>>      rm(list=".Random.seed", envir= .GlobalEnv)
>>    } else {
>>      assign(".Random.seed", value=oseed, envir= .GlobalEnv)
>>    }
>>  })
>> 
>> to avoid that warning.  So, having support functions for this in base
>> R would be helpful, e.g.
>> 
>>  oseed <- base::getRandomSeed()
>>  on.exit(base::setRandomSeed(oseed))
>> 
>> Back to Marvin's point/question.  I think it would be useful if the
>> CRAN Policies would explicitly say that functions must not change the
>> random seed to a fixed one, without undoing it, unless the user
>> specifies it via an argument.  If not, there's a great risk it will
>> mess up statistical analysis.  Also, if there would a way to test
>> against such practices, which I think is really hard, I would be the
>> first one backing it up.
>> 
>> On a related note; there are packages that forward the .Random.seed
>> when loaded.  This is also an unfortunate behavior because you will
>> give different RNGs depending on that package was already loaded
>> before you called a function that depends on it or not.  For example,
>> if pkgA forwards the .Random.seed when loaded, the following is *not*
>> reproducible:
>> 
>> # User might or might not have loaded pkgA already
>> if (runif(1) < 0.5) loadNamespace(pkgA)
>> 
>> set.seed(0xBEEF)
>> loadNamespace(pkgA)
>> y <- runif(1)
>> 
>> I ran into this problem when doing some strict testing.  I argue this
>> also falls into the set of "bad" practices to be avoided.
>> 
>> /Henrik
>> 
>> On Wed, Oct 30, 2019 at 6:23 AM Duncan Murdoch <murdoch.dun...@gmail.com> 
>> wrote:
>>> 
>>> On 30/10/2019 9:08 a.m., peter dalgaard wrote:
>>>> We commit a similar sin in the help pages, e.g.
>>>> 
>>>> example(set.seed) ; runif(2)
>>>> example(set.seed) ; runif(2)
>>>> 
>>>> gives you the same random uniforms both times. (Of course it isn't that 
>>>> much of an issue, since you would rarely be running examples before any 
>>>> serious simulations.)
>>> 
>>> I think it's pretty common in example code, and that's justifiable.  But
>>> it could be avoided by using withr::with_seed() or something equivalent.
>>> 
>>> Duncan Murdoch
>>> 
>>>> 
>>>> You can fairly easily work around that by saving and restoring 
>>>> .Random.seed. I wonder if that isn't also true of the cases using 
>>>> set.seed() for other reasons?
>>>> 
>>>> -pd
>>>> 
>>>> 
>>>>> On 30 Oct 2019, at 13:46 , Duncan Murdoch <murdoch.dun...@gmail.com> 
>>>>> wrote:
>>>>> 
>>>>> On 30/10/2019 3:28 a.m., Marvin Wright wrote:
>>>>>> Hi all,
>>>>>> I recently found several calls of set.seed() in a CRAN package. These 
>>>>>> calls are in a plot function, which could lead to unexpected behaviour. 
>>>>>> See https://github.com/sammo3182/interplot/issues/33 
>>>>>> <https://github.com/sammo3182/interplot/issues/33> for a description of 
>>>>>> the problem.
>>>>>> I checked the CRAN repository policies and could not find anything about 
>>>>>> this. I would have expected a policy against setting fixed seeds 
>>>>>> somewhere in a package. Am I missing something?
>>>>> 
>>>>> set.seed() writes .Random.seed in the user's global environment, which 
>>>>> violates this policy:
>>>>> 
>>>>> - Packages should not modify the global environment (user’s workspace).
>>>>> 
>>>>> However, every call to a random number generator creates or modifies 
>>>>> .Random.seed as well, and most of those are expected and shouldn't be 
>>>>> flagged.  And interplot() is documented to do random simulations, so it 
>>>>> would be expected to change the seed:  the issue is that given the same 
>>>>> inputs it always changes it to the same thing.  I think that would be 
>>>>> quite hard for a test to detect.
>>>>> 
>>>>> Should it be a policy with no test?  Maybe, because I agree with you that 
>>>>> interplot()'s set.seed(324) is bad practice.
>>>>> 
>>>>> Duncan Murdoch
>>>>> 
>>>>> ______________________________________________
>>>>> R-devel@r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> 
>>> 
>>> ______________________________________________
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to