-
Notifications
You must be signed in to change notification settings - Fork 19.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use local RandomState instead of seeding the global RNG #12259
Use local RandomState instead of seeding the global RNG #12259
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the PR. We'll merge after the other PR has been merged, since it was created before.
I don't know how we ended up in situation with two similar PRs. What I usually do is I search for similar PRs which haven't been merged yet before contributing, and if there are some - I either suggest changes to those or create a new PR with non-overlapping changes. |
Looks like #12232 was closed in favor of this one |
Oh hi. I just want to point out some possible optimization. In |
Just the diff for my suggestion. |
@ConcurrencyPractitioner can you make that a PR please? |
…2259) * Use local RandomState instead of seeding the global RNG * Create a unit test module for datasets and move tests there * Move initializer test to the proper file
Summary
According to NumPy NEP 19 — Random Number Generator Policy, instantiating local
RandomState
objects is preferred, rather than seeding the globalnp.random
generator.Seeding the global generator may introduce unexpected behavior in the applications that use Keras and also rely on its state.
Proposed change: use a local
RandomState
object in dataset loaders and the Orthogonal initializer.Related Issues
#12258
PR Overview