kmeans_inducing_points is non-reproducibly random

[JohnGoertz]

Calling kmeans_inducing_points from gp.utils results in different values every time, with no way to specify a random seed.

It appears that function wraps Scipy's kmeans, which takes its random seed from np.random.seed(), so it should be a quick fix to add a random_seed kwarg that just gets passed to np.random.seed() before calling scipy. I'm not sure if that would have broader unintended consequences, such as if the user had subsequent calls to np.random. However, if the user is calling kmeans with a specified random seed, they likely want their whole workflow to be reproducibly random, so maybe it wouldn't be an issue? Additionally, new code should use the more recent numpy random Generator, which np.random.seed() shouldn't affect.

• PyMC3 Version: 3.11.2
• Theano Version: 1.0.5
• Python Version: 3.8.5

[twiecki]

CC @bwengals

[twiecki]

Thanks @JohnGoertz, want to do a PR that fixes this?

[OriolAbril]

so it should be a quick fix to add a random_seed kwarg that just gets passed to np.random.seed() before calling scipy. I'm not sure if that would have broader unintended consequences, such as if the user had subsequent calls to np.random

I think we should not go with this proposal. numpy.random.seed has a global effect so it will definitely affect any posterior calls to np.random.<distribution> and it should not be used anymore (even if using the old RandomState instead of the new Generator see its api docs and general recommendations for the random module). This may mean that the fix needs to happen upstream in scipy though.

[JohnGoertz]

Oh, wouldn't you know it, a PR fixing this exact problem was merged into scipy just a few weeks ago: scipy/scipy#13972

Guess we just gotta wait for 1.7.0 to be released.

[OriolAbril]

Amazing, then we only have to expose the seed argument and pass it to scipy 🎉

[bwengals]

Fixed by #5055. One can now pass in arbitrary kwargs to kmeans_inducing_points that get passed on to the scipy routine.