Remove rng seeder

[ricardoV94]

This PR removes the Model(rng_seeder=seed) API as discussed in #5785 and instead makes use of the random_seed kwarg in all sampling functions. One big breaking change done on purpose (but not strictly needed) is that these functions will not care/respect user defined external global seeding.

import pymc as pm
import numpy as np

with pm.Model() as m:
  x = pm.Normal("x")
  np.random.seed(0)  # DOES NOT MATTER!
  always_different = pm.sample()
  always_the_same = pm.sample(random_seed=0)

This is done so that default seeding quality can be "as good as possible", as suggested by NumPy best practice: https://numpy.org/doc/stable/reference/random/bit_generators/generated/numpy.random.SeedSequence.html#numpy.random.SeedSequence

# Global seeding is ignored by numpy default_rng, 
# and that's why our PyMC sampling functions now do the same:
import numpy as np

np.random.seed(0)
print(np.random.default_rng(None).random())  # 0.7166779009481196
np.random.seed(0)
print(np.random.default_rng(None).random())  # 0.6145552524375484

Is everyone okay with this change?

Also allowed passing RandomState or Generators to all sampling functions for user convenience.

rng = np.random.default_rng()
with pm.Model() as m:
  x = pm.Normal("x")
  pm.sample(random_seed=rng)

Closes #5785
Closes #5733
Closes #5784
Closes #4301

[codecov]

Codecov Report

Merging #5787 (7096547) into main (d0af6b1) will increase coverage by 0.01%.
The diff coverage is 97.67%.

@@            Coverage Diff             @@
##             main    #5787      +/-   ##
==========================================
+ Coverage   89.36%   89.38%   +0.01%     
==========================================
  Files          74       74              
  Lines       13804    13764      -40     
==========================================
- Hits        12336    12303      -33     
+ Misses       1468     1461       -7     

Impacted Files	Coverage Δ
pymc/tuning/starting.py	92.56% <ø> (-0.13%)	⬇️
pymc/parallel_sampling.py	87.45% <66.66%> (+0.74%)	⬆️
pymc/sampling.py	88.70% <97.67%> (+0.27%)	⬆️
pymc/aesaraf.py	91.89% <100.00%> (+0.27%)	⬆️
pymc/distributions/censored.py	93.02% <100.00%> (-1.72%)	⬇️
pymc/distributions/distribution.py	90.83% <100.00%> (+0.62%)	⬆️
pymc/distributions/mixture.py	96.75% <100.00%> (-0.31%)	⬇️
pymc/distributions/timeseries.py	77.46% <100.00%> (-0.09%)	⬇️
pymc/initial_point.py	99.09% <100.00%> (-0.91%)	⬇️
pymc/model.py	86.52% <100.00%> (-0.30%)	⬇️
... and 7 more

[michaelosthege]

@ricardoV94 I can't invest the time for a thorough review right now---the diff is a little big and seeding is a sensitive and tricky topic..

[lucianopaz]

I have a bunch of questions @ricardoV94. The aesaraf functions look good but I have some questions regarding sampling. How does the random seed go into the step methods at the moment? The idea of passing different "seeds" (the entropy parameter) to SeedSequence isn't the best way to ensure independent streams. The best way is to spawn as many seeders as necessary. These will all get the same entropy value, but they'll have different spawn_keys. We should aim to use this instead of different entropies somehow.

[ricardoV94]

I have a bunch of questions @ricardoV94. The aesaraf functions look good but I have some questions regarding sampling. How does the random seed go into the step methods at the moment? The idea of passing different "seeds" (the entropy parameter) to SeedSequence isn't the best way to ensure independent streams. The best way is to spawn as many seeders as necessary. These will all get the same entropy value, but they'll have different spawn_keys. We should aim to use this instead of different entropies somehow.

In forward sampling, we always go via a single compile_pymc and we do a single SeedSequence(seed).spawn(len(rngs)). This should be optimal.

In MCMC sampling, all our step methods rely on global seeding. We have to create different integer seeds for each chain. Ideally we would be passing Generators around instead, and we would probably spawn them (or their SeedSequences) before branching off. This however will require a larger refactoring. See #5093

[lucianopaz]

Looks very good @ricardoV94 !

[lucianopaz]

@ricardoV94, I’ll let you merge since I’m not sure if you want to squash merge or rebase and preserve the history

[ricardoV94]

@ricardoV94, I’ll let you merge since I’m not sure if you want to squash merge or rebase and preserve the history

Always rebase with me :)

[ricardoV94]

Thanks for reviewing!