fix: use stable seeds in PyTorch notebooks - #644
Open
marcus-campbell wants to merge 1 commit into
Open
marcus-campbell wants to merge 1 commit into
marcus-campbell wants to merge 1 commit into
Conversation
Replace process-randomized hash-derived seeds with fixed integer seeds so the PyTorch and Lightning examples initialize their RNGs consistently across Python processes.
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
5 tasks
mdlinville
added a commit
to wandb/docs
that referenced
this pull request
Sep 14, 2026
## Description
The PyTorch integration page says this setup ensures deterministic
behavior, but it doesn't appear to actually do that. This is because it
derives its seeds from `hash("...")`. By default, Python randomizes
string hashes _between_ interpreter processes, so the example can
initialize its RNGs differently across runs.
This fix replaces the hash-derived values with one named integer seed.
Before:
```python
torch.backends.cudnn.deterministic = True
random.seed(hash("setting random seeds") % 2**32 - 1)
np.random.seed(hash("improves reproducibility") % 2**32 - 1)
torch.manual_seed(hash("by removing stochasticity") % 2**32 - 1)
torch.cuda.manual_seed_all(hash("so runs are repeatable") % 2**32 - 1)
```
After:
```python
seed = 42
torch.backends.cudnn.deterministic = True
random.seed(seed)
np.random.seed(seed)
torch.manual_seed(seed)
torch.cuda.manual_seed_all(seed)
```
### Why this matters
A small exploratory search found the same recognizable recipe in at
least 24 other repositories. This suggests that the pattern has
propagated beyond W&B's own docs, so correcting the bug here can help
prevent it from spreading further.
The problem was also noted in the technical-review notes for
[#2673](#2673), but it wasn't fixed as
it was out-of-scope for that PR (it was a style guide pass).
The corresponding notebooks are updated in
[wandb/examples#644](wandb/examples#644).
## Testing
- [x] `git diff --check` succeeds.
- [x] Confirmed that the diff contains only the intended seed changes.
- [x] Confirmed that the old hash-derived seeds vary with
`PYTHONHASHSEED`.
- [x] Confirmed that the replacement has no interpreter hash-secret
dependency.
- [ ] PR tests succeed.
Co-authored-by: Matt Linville <mlinville@coreweave.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Several PyTorch notebooks here state they behave deterministically, but they don't appear to actually do that. This is because they derive their seeds from
hash("..."). Python randomizes string hashes between interpreter processes, so these notebooks can actually initialize their RNGs differently across runs.This updates:
To make this fix, I had to replace the "self-commenting hashes" - for example,
hash("setting random seeds")- with a named integer seed, so the code has lost a bit of its former character. If y'all want this recovered somehow (perhaps a short comment), just let me know.Why this matters
I found this while researching a prototype Ruff rule for reproducibility problems. I ran a small exploratory search for this pattern, and the same recognizable recipe appeared in at least 24 other repositories. This suggests that the pattern here has propagated beyond W&B's own examples, so correcting this now can help prevent the problem from spreading further.
I've also submitted wandb/docs#3072, which updates the corresponding
wandb/docspage, which contains the same bug.Testing
PYTHONHASHSEED.