01-experiment-tracking records a run's hyperparameters faithfully, but hyperparameters alone don't fully determine a training run's outcome: weight initialization, data shuffling, and dropout all involve randomness, and a training run is only truly REPRODUCIBLE if every one of those independent random sources is pinned to a known seed. Missing even one, a genuinely common mistake, since a language's built-in RNG and NumPy's RNG are completely separate systems, silently breaks reproducibility.
Implement seeded_numpy_sequence and seeded_python_random_sequence (two GENUINELY SEPARATE random number sources, each independently seedable), capture_reproducibility_config (bundling both seeds for logging), and verify_reproducible (the actual practical test of whether reproducibility holds).
seeded_numpy_sequence(seed, n) uses np.random.default_rng(seed); the same seed must always produce the same sequence.seeded_python_random_sequence(seed, n) uses Python's own random.Random(seed): a genuinely independent generator from NumPy's.verify_reproducible(fn, seed, num_trials) calls fn(seed) num_trials times and returns True only if every call produces an identical result.Open one at a time. Each gives away a little more than the last.
random.Random(seed) creates a fresh, independent generator instance (as opposed to random.seed(seed), which mutates Python's single GLOBAL generator): using an instance keeps this exercise's functions free of hidden global state, exactly the kind of hidden state that makes real reproducibility bugs hard to track down.
verify_reproducible doesn't need to know anything about WHAT fn does internally: it just calls it several times with the same seed and checks all the results match, using np.array_equal so it works whether fn returns a NumPy array or a plain Python list.
No results yet
Run your code to check it against the examples, or submit to run every test.