Use np.random.Generator to generate random numbers#9005
Use np.random.Generator to generate random numbers#9005
Conversation
np.random.Generator is the replacement for np.random.RandomState which is effectively frozen. Use Generator by default and keep RandomState for now for backward compatibility. Fixes (dask#8790)
do not assume that random has only one argument (aside from chunks). case in point: np.random.Generator breaks this assumption.
and so does not raise the exception. Use standard_cauchy instead
and test permutations with both RandomState and Generator classes
as it is no longer available with np.random.Generator. Use da.random.integers instead
|
Can one of the admins verify this patch? |
old da.random.random signature: random.RandomState.random_sample(size=None) new da.random.random signature: random.Generator.random(size=None, dtype=np.float64, out=None) we cannot continue using random_sample as it is removed from new generators. in other words, chunks needs to be specified and not assumed to be the second argument
|
1/
random_sample is removed in
so, In other words, this is a breaking change. Are we allowed to do that? 2/
I do not have easy access to a windows environment and it looks like a known windows weirdness. How should we proceed? |
|
so all tests pass but 1/ All platforms: 2/ Windows Only: Is this acceptable? |
|
add to allowlist |
jsignell
left a comment
There was a problem hiding this comment.
Thanks for taking this on! I think it's broadly fine to change behavior, but if possible we try to deprecate or at least raise an informative error.
|
continued on PR #9038. Closing |
dask.array.default_rng#8790pre-commit run --all-filesFirst pass at using np.random.Generator instead of deprecated np.random.RandomState class. Keep backward compatibility and make deprecation and switching over easy. Please let me know if an alternative approach is preferable.
Had a quick look and it should be relatively easy to change internal RandomState usage to Generator