We can see the single node with [id A], has two outputs, which we named next_rng and x. By default only the second output x is given to the user directly, and the other is "hidden".
...
...
@@ -226,14 +225,14 @@ This is exactly what RandomStream does behind the scenes
The destroy map annotation tells us that the first output of the x variable is allowed to alter the first input.
The destroy map annotation tells us that the first output of the x variable is allowed to modify the first input.
>>> %timeit inplace_f() # doctest: +SKIP
35.5 µs ± 1.87 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)
9.71 µs ± 2.06 µs per loop (mean ± std. dev. of 7 runs, 100000 loops each)
Performance is now much closer to calling numpy directly, with only a small overhead introduced by the PyTensor function.
Performance is now much closer to calling NumPy directly, with a small overhead introduced by the PyTensor function.
The `random_make_inplace <https://github.com/pymc-devs/pytensor/blob/3fcf6369d013c597a9c964b2400a3c5e20aa8dce/pytensor/tensor/random/rewriting/basic.py#L42-L52>`_
rewrite automatically replaces RandomVariable Ops by their inplace counterparts, when such operation is deemed safe. This happens when:
#. An input RNG is flagged as `mutable` and is used in not used anywhere else.
#. A RNG is created intermediately and used in not used anywhere else.
#. A RNG is created intermediately and not used anywhere else.
The first case is true when a users uses the `mutable` `kwarg` directly, or much more commonly,
when a shared RNG is used and a (default or manual) update expression is given.
In this case, a RandomVariable is allowed to modify the RNG because the shared variable holding it will be rewritten anyway.
The second case is not very common, because RNGs are not usually chained across multiple RandomVariable Ops.
See more details in the next section.
The first case is true when a users uses the `mutable` `kwarg` directly.
It works, but that graph is slightly unorthodox in Pytensor.
It works, but that graph is slightly unorthodox in PyTensor.
One practical reason is that it is more difficult to define the correct update expression for the shared RNG variable.
One practical reason why, is that it is more difficult to define the correct update expression for the shared RNG variable.
One techincal reason is that it makes rewrites more challenging in cases where RandomVariables could otherwise be manipulated independently.
One techincal reason why, is that it makes rewrites more challenging in cases where RandomVariables could otherwise be manipulated independently.
Creating multiple RNG variables
-------------------------------
RandomStreams generate high quality seeds for multiple variables, following the NumPy best practices https://numpy.org/doc/stable/reference/random/parallel.html#parallel-random-number-generation.
Users who create their own RNGs should follow the same practice!
Users who sidestep RandomStreams, either by creating their own RNGs or relying on RandomVariable's default shared RNGs, should follow the same practice!
Random variables in inner graphs
================================
...
...
@@ -629,7 +613,7 @@ RNGs in Scan are only supported via shared variables in non-sequences at the mom
>>> print(err)
Tensor type field must be a TensorType; found <class 'pytensor.tensor.random.type.RandomGeneratorType'>.
In the future, TensorTypes may be allowed as explicit recurring states, rendering the use of updates optional or unnecessary
In the future, RandomGenerator variables may be allowed as explicit recurring states, rendering the internal use of updates optional or unnecessary
OpFromGraph
-----------
...
...
@@ -671,7 +655,7 @@ Other backends (and their limitations)
Numba
-----
NumPy random generator can be used with Numba backend.
NumPy random generators can be natively used with the Numba backend.
JAX uses a different type of PRNG than those of Numpy. This means that the standard shared RNGs cannot be used directly in graphs transpiled to JAX.
JAX uses a different type of PRNG than those of NumPy. This means that the standard shared RNGs cannot be used directly in graphs transpiled to JAX.
Instead a copy of the Shared RNG variable is made, and its bit generator state is given a jax_state entry that is actually used by the JAX random variables.
Instead a copy of the Shared RNG variable is made, and its bit generator state is expanded with a jax_state entry. This is what's actually used by the JAX random variables.
In general, update rules are still respected, but they won't be used on the original shared variable, only the copied one actually used in the transpiled function
In general, update rules are still respected, but they won't update/rely on the original shared variable.
