[mameikagou]

Fixes #868.

Replaces the private SciPy import with the BSD-licensed rng_integers implementation and adds compatibility coverage for RandomState, Generator, and the global NumPy random state.

Tests:

• pytest quantecon/util/tests/test_random.py (5 passed)
• flake8 --select=F401,F405,E231 quantecon
• Full suite: 653 passed; the notebook dependency test failed while connecting to raw.githubusercontent.com.

[mmcky]

Thanks @mameikagou — this is verified and in good shape. The vendored function matches SciPy's implementation exactly across 18 comparisons (both RandomState and Generator, endpoint either way, size as None, an int and a tuple, and the high=None form), the private scipy._lib._util import is gone, and the quantecon/util tests pass.

We are holding it rather than merging, because #877 — settling our migration path from legacy RandomState to NumPy Generator — turns out to govern the shape of this helper rather than merely sit alongside it. SciPy's implementation resolves gen=None to np.random.mtrand._rand, the legacy global singleton, and that is exactly the choice #877 exists to make; adopting the SciPy version wholesale would settle it by default. There is also a licensing question worth raising: QuantEcon.py is MIT and SciPy is BSD-3, so vendoring brings a licence block with it, where quantecon/util/compat.py carries a one-line attribution for code from the same SciPy file.

So the approach may change — writing a small adapter of our own is one option, since the logic is dictated by the two NumPy APIs — and I would rather settle that on #877 than ask you to guess. I have put a concrete proposal there to move it along. Apologies for the delay on a first contribution; the underlying problem in #868 is real and worth fixing, and none of this is a criticism of the work.