Skip to content

Change user-facing random variable API#1707

Draft
ricardoV94 wants to merge 3 commits intopymc-devs:mainfrom
ricardoV94:rng_methods
Draft

Change user-facing random variable API#1707
ricardoV94 wants to merge 3 commits intopymc-devs:mainfrom
ricardoV94:rng_methods

Conversation

@ricardoV94
Copy link
Member

@ricardoV94 ricardoV94 commented Oct 29, 2025

This PR gets rid of RandomStream, and provides as an alternative random methods on RandomGeneratorType variables.

So one can do:

rng = random_generator_type("rng")  # symbolic equivalent to np.random.Generator
next_rng, x = rng.normal()
fn = function([rng], x)
fn(np.random.default_rng(1)  # draws

rng can obviously be a shared variable, and have an update {rng: next_rng}, which is a bit what RandomStream is doing under the hood.

However, everything is now explicit. There are no longer any default_updates, and unlike numpy the user is given the output next_rng to use afterwards. This is a bit awkward, but it's the most explicit API?

The RandomStream had important issues in rewrites, because of the default_update graphs are implicit, and when one mutates a graph with such variables they would also need to mutate the default_update graph for the final thing to be correct.

RandomVariable Ops will no longer hide the next_rng output like they used to. There's a transition period forcing you to commit to the new flag return_next_rng, which will eventually default to True if unspecified

next_rng, x = pt.random.normal(rng=rng, return_next_rng=True)

@ricardoV94 ricardoV94 added this to the 3.0 release milestone Jan 29, 2026
@ricardoV94 ricardoV94 changed the title Rng methods Change user-facing random variable API Jan 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant