Jesse Grabowski

Sure, I'll make a new file. It's just not my default. I agree it doesn't belong in basic.

Not quite 1:1 on numpy features but close. The more exotic padding schemes I would need more time to understand. Still needs jax/numba overloads, but these should be very trivial.

I like both the proposal and the counter-proposal. While I don't love it, I'll also throw into the mix the `import statsmodels.api as sm` pattern. They provide the `api` module...

It's just a [script ](https://github.com/statsmodels/statsmodels/blob/main/statsmodels/api.py)that imports from around their modules in a user-facing way. The consequence is that you have to do `import statsmodels.api as sm`, but the benefit is...

I'm trying to understand this issue to start a PR. What actually needs to be done? Numba functions can take numpy random generators without any hassle now. For example, this...

But I'm saying I'm pretty sure you can directly plug a generator into what they already have? There's even a numba datatype for numpy random generators (`nb.types.NumPyRandomGenerator`)

The broadcasting is done with a loop, so it's actually not too bad. Here is a basic sketch: ```python import numba as nb import numpy as np @nb.njit def draw_nb(rng,...

No, you have to write overloads on a case-by-case basis. But that should be a hassle, not a blocker. Also it already exists. The current code jumps through a lot...

So I guess there are two issues being discussed here: 1. Can we eliminate the RandomStream objects and just use RandomGenerators (I think yes) 2. Does there need to be...

Could be! I've let this project fall to the wayside, but I need to come back to it in the coming weeks/months, so I'm keen to collaborate on it. Could...