R devel - Oct 2019 - set.seed() in a package

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?

Best, 

Marvin
	[[alternative HTML version deleted]]

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

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.)

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
-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com