Primarily, this pull requests updates the functions and classes which rely on random number generation to be able to reproduce their results with a unified interface.
Any function which uses an RNG now accepts rng as an argument. By default if no RNG is supplied, one will be initialized via numpy's default_rng function.
Any class which has methods that themselves use RNGs can now store their RNG as a property
Tests have been added to ensure reproducibility based on recreation of analogous objects
These should be relatively minimal changes which help improve the reproducibility. There is still, however, a bit of gray area of undefined/unclear behavior when class methods, such as Generator.from_generator, are used to instantiate new copies of objects. Right now, the RNG referred to by the Generator property will be deep copied into the new Generator object. Whether or not this is semantically consistent behavior, or requires a warning, is still a bit unclear to me. I'll decide what that behavior should look/feel like globally and implement that (alongside warnings and documentation) in a future PR.
Primarily, this pull requests updates the functions and classes which rely on random number generation to be able to reproduce their results with a unified interface.
rngas an argument. By default if no RNG is supplied, one will be initialized via numpy'sdefault_rngfunction.These should be relatively minimal changes which help improve the reproducibility. There is still, however, a bit of gray area of undefined/unclear behavior when class methods, such as
Generator.from_generator, are used to instantiate new copies of objects. Right now, the RNG referred to by the Generator property will be deep copied into the new Generator object. Whether or not this is semantically consistent behavior, or requires a warning, is still a bit unclear to me. I'll decide what that behavior should look/feel like globally and implement that (alongside warnings and documentation) in a future PR.