Robert Kern

`Multivector` objects are also sequences. `np.array()` consumes sequences as if they were lists. To create a `dtype=object` array of sequences, the magic of `np.array()` that automatically determines the shape of...

> * For parallel use: quite easy to shoot yourself in the foot, users have to realize that they need to switch paradigm and then fiddle with `SeedSequence` or `.jumped`....

Specifically, this code: ```python # NumPy parallel sseq = np.random.SeedSequence(entropy=seed) child_seeds = sseq.spawn(4) rngs = [np.random.default_rng(seed=s) for s in child_seeds] ``` would become: ```python rngs = rng.spawn(4) ```

I'm perfectly content with having 0 PRNG APIs in the standard (and far prefer 0 in the standard to having 2 in the standard). It seems like there is significant...

Not much.

We can build shim APIs across either implementation to get stateless or stateful APIs, but the way that each shim API needs to be implemented has its own costs, constraints,...

It's, uh, getting long. Not because my list of issues is long, just that I am long-winded and am including a lot of background.

## Apologies This is long, and everyone has my apologies for that, but I want to make sure the background is laid out. ## Introduction So first off, I want...

> If I understand Robert's post above correctly, you're trying to convince us this is one of the rare cases where API design is tightly coupled to the underlying algorithm....

Another way to think about it is that all PRNG schemes have a certain finite amount of safety margin, and it is a _consumable_ resource. Just serially drawing arrays of...