From murdoch@dunc@n @end|ng |rom gm@||@com  Wed Oct 30 13:46:47 2019
From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch)
Date: Wed, 30 Oct 2019 08:46:47 -0400
Subject: [Rd] set.seed() in a package
In-Reply-To: <B880EAC4-01D4-4588-BAE2-D4337A10378A@wrig.de>
References: <B880EAC4-01D4-4588-BAE2-D4337A10378A@wrig.de>
Message-ID: <7e3c5f47-e9b4-0e18-573f-5499f444c21a@gmail.com>

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



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