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
