We already have such an interface, see Parallel Random Number Generation. If you couldn't find it that means we need to somehow make it more discoverable, so I am pivoting this to a documentation issue.

@mattip Please don't be so fast to blame your documentation. I didn't look hard enough. I'm goign to read it now.

Looks like an excellent design. I guess you could use the word "splittable" and "fork" somewhere on the page so that Google finds it. This is the terminology used by Jax.

Maybe we should have keyword lists in the documentation.

Good idea. Anyway, feel free to close this. I've tried to convince the Jax people to use your interface: jax-ml/jax#2294 If they agree, the ambiguity will disappear.

While the current API forces you to work with SeedSequences directly to access its spawn() method, we did make sure that it would be possible to expose spawn() methods on BitGenerator and Generator, which will be more convenient. We wanted to wait until we got a little more experience with the concept before exposing it so prominently.

Just to provide some mathematical background, Jax's PRNG is in the same weak-crypto family as our Philox BitGenerator. The method by which it splits only works well for that family of weak-crypto PRNGs because that family keeps its initial seed around as the key value and only evolves a counter as one draws numbers from it. The other PRNGs iterate the state.

SeedSequence implements a similar scheme, but separates that scheme out from the PRNG implementation. By keeping the original seed state around as SeedSequence and by implementing good integer hashing techniques, we can get the same benefits without needing the full weak-crypto functionality of the PRNG. This may be of particular interest to the Jax developers since the ThreeFry algorithm that they use is not the fastest, nor necessarily the most GPU-friendly (once the massive-parallelization playing field is leveled by SeedSequence). They might be able to use a faster PRNG like SFC64 (our default of PCG64 may not be appropriate on a GPU because it requires 128-bit multiplication).

@rkern I wish there was a fascinating reaction, because that is fascinating. I'll point them to your comment.

Note that Philox, and the Threefry PRNG, and SFC are merely examples of a general construction called the "counter-based PRNG" (as used in the "Random123" paper). In general, counter-based PRNGs use an underlying hash function or block cipher to hash a seed and an incrementing counter. And any other hash function can substitute for Threefry (or whatever underlying function the counter-based PRNG uses) as long as the resulting PRNG provides adequate randomness.

Also, splittable PRNGs are far from being an "innovation" of JAX (see also the JAX PRNG design notes); they have existed, for example, in Haskell and Java for years. Some of the known constructions for splittable PRNGs are surveyed in "Evaluation of Splittable Pseudo-Random Generators" by H. G. Schaathun, 2015. Some of them are general enough to be used by any PRNG (including Mersenne Twister and PCG), but do not necessarily lead to high-quality splittable PRNGs. Another example of a splittable PRNG is found in JuliaLang/julia#34852. See also idontgetoutmuch/random#7.

Just for the record, note that SFC64 is not actually counter-based. It incorporates a counter into its state, but the counter isn't the only part of the state that evolves a la ThreeFry and Philox. The counter in SFC64 is there to ensure a minimum size of the cycles, which are of variable size.