There's a doc_string test (line ~292 in scipy/sparse/linalg/_eigen/_svds.py ) that I've kept using kwarg random_state=rng because rng is set to be RandomState(0) and if I change that, the resulting values must be changed a few lines below.

    >>> rng = np.random.RandomState(0)
    >>> X_dense = rng.random(size=(100, 100))
    >>> X_dense[:, 2 * np.arange(50)] = 0
    >>> X = sparse.csr_array(X_dense)
    >>> _, singular_values, _ = svds(X, k=5, random_state=rng)
    >>> print(singular_values)
    [ 4.3293...  4.4491...  4.5420...  4.5987... 35.2410...]

I could change the first line I've shown here to use default_rng, change the kwarg and change the values printed. But IIUC its better to leave random_state in order to minimize these changes. We'll deal with them upon removal.

Do I understand correctly? Let me know if I should change the test from using RandomState to using default_rng.

Do I understand correctly? Let me know if I should change the test from using RandomState to using default_rng.

Please do change it, actually. It is good to do it now because we want new users who refer to the examples to use rng. And if it were not done now, it would need to be done in two versions when the decorator begins to emit warnings about use of random_state.

I think this addresses all points brought up -- and lead to a couple others which were easy to fix.

One last point is that if random_array PR gh-21888 gets merged first, this one could change quite a few random_array calls to use rng= instead of random_state=. Both should work during the transition, so I think that's OK... but if we switch them now it makes the next transition simpler.

I made all all svds tests deterministric and all propack tests that directly call _svpd deterministic.
The number of changes to make the tests deterministic is fairly large.

Every function call to _svdp now specifies rng. It is still an "optional" argument though, so I added code to normalize the input rng inside _svpd unless it is a RandomState. I could put back the check_random_state code if that is preferred.

@dschult I'm not sure I understand - does _svdp only work with aGenerator? Why does it need to have normalization inside it?

Oops.. somehow I didn't commit my last set of changes.
pushed before committing i guess.

_svdp should work without any normalization because everything that calls it has already normalized it. That said, if someone has been using it on their own despite it being private, if/when they don't provide an rng arg is defaults to None, which creates a strange error message. So, I put code to check if rng is None and raise a ValueError if that happens. But it would only happen if someone if directly using the private function.

Just to be clear: It should work with a RandomState or a Generator instance as rng. What we are removing is the handling of int and None, which should be OK because it is private.

I am bit confused with this one here, I am receiving some errors while trying to enable the rng in #22748 but the check_random_state is generating instances of np.random.mtrand._rand. Shouldn't it create default_rng() when rng argument is None?

Immediately changing to that behavior would have been backward incompatible. The decorator _transition_to_rng converts arguments passed by rng keyword to a default_rng; otherwise, the decorator emits a warning and check_random_state does what it always has.

True but if rng=None then it does not matter the type of the PRNG object we create since there is no argument given. So instead of RandomState, check_random_state can produce a Generator already. Or am I misunderstanding?

It depends on if the global seed has been set. If so, it needs to use the global RandomState produced by check_random_state. If not, it is ok to use an unseeded RandomState produced by check_random_state because that is interchangeable, as far as the function should be concerned, with an unseeded Generator. In that case, it would also be ok for the decorator to produce an unseeded Generator, but for simplicity, it only changes behavior now if rng is passed by keyword.

Ah OK so this is from the np.random.seed(int) cases. Thanks.