Displaying 4 results from an estimated 4 matches for "with_seed".
2019 Oct 30
2
set.seed() in a package
...ves 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
> >
> >
> >> O...
2019 Oct 30
2
set.seed() in a package
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
2019 Oct 30
0
set.seed() in a package
...>
> 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 <...
2019 Oct 30
0
set.seed() in a package
...e 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...