From murdoch@dunc@n @end|ng |rom gm@||@com  Wed Oct 30 14:22:37 2019
From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch)
Date: Wed, 30 Oct 2019 09:22:37 -0400
Subject: [Rd] set.seed() in a package
In-Reply-To: <03E4EF62-11A2-47EE-854F-FF872F19E2FA@gmail.com>
References: <B880EAC4-01D4-4588-BAE2-D4337A10378A@wrig.de>
 <7e3c5f47-e9b4-0e18-573f-5499f444c21a@gmail.com>
 <03E4EF62-11A2-47EE-854F-FF872F19E2FA@gmail.com>
Message-ID: <e2f26e0b-5499-1eb4-55f6-c063c15c2622@gmail.com>

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.duncan at 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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>



[Rd] set.seed() in a package
Duncan Murdoch