DOC: stats: document RNG behavior when distribution is deepcopied #17829
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tylerjereddy
added a commit
to tylerjereddy/scipy
that referenced
this pull request
Jan 20, 2023
* the `setup.py` MacOS Python `3.8` CI job is starting to fail with timeouts for multiprocessing `Pool`-related code in recent PRs like scipygh-17777 and scipygh-17829 * nothing stands out in the build logs when I do a side-by-side diff, and the GHA job history seems to suggest the failure doesn't happen every time the CI is flushed, but perhaps more often lately * make a few cleanups here in attempt to fix * first off, we can simplify the Pythran config--there's only one job left in this file after the splitting with `meson`, and it is Python `3.8` (`3.8` support may be on the way out too, but I'm assuming we delay that a tiny bit more perhaps) * previous discussions like scipy#11835 with MacOS Python 3.8 multiprocessing Pool hangs were complicated, but sometimes using `runtests.py` (which is also on the way out I think..) contributed to hangs b/c of multiprocessing import orders. So, try to use `pytest` directly instead to see if it helps * I suspect these changes are "just fine" to apply even if we're going to switch to 3.9 minimum sooner than later
tylerjereddy
added a commit
to tylerjereddy/scipy
that referenced
this pull request
Jan 21, 2023
* the `setup.py` MacOS Python `3.8` CI job is starting to fail with timeouts for `multiprocessing` `Pool`-related code in recent PRs like scipygh-17777 and scipygh-17829 * nothing stands out in the build logs when I do a side-by-side diff vs. succeeding versions of the job, and the GHA job history seems to suggest the failure doesn't happen every time the CI is flushed, but perhaps more often lately * make a few cleanups here in attempt to fix - previous discussions like scipygh-11835 with MacOS Python 3.8 `multiprocessing` `Pool` hangs were complicated, but sometimes using `runtests.py` contributed to hangs b/c of `multiprocessing` import orders. So, try to use `pytest` directly instead to see if it helps. - we can simplify the Pythran config--there's only one job left in this file after the splitting with `meson`, and it is Python `3.8` - I've also extended the timeout limit a little bit, and since GHA MacOS runners have 3 cores I've tried using all 3 for the testsuite here because I once had the job pass on my fork during testing, but it took 66 minutes: #65 * I think there's still something a bit weird here, so it is a combination of measures that seemed to help a bit on my fork but perhaps long-term the removal of Python 3.8 support along with sunsetting `runtests.py` means that this mess may disappear before we need to dig much deeper [skip azp] [skip circle] [skip cirrus]
dschmitz89
approved these changes
Jan 21, 2023
tupui
approved these changes
Jan 23, 2023
tylerjereddy
added a commit
to tylerjereddy/scipy
that referenced
this pull request
Feb 12, 2023
* the `setup.py` MacOS Python `3.8` CI job is starting to fail with timeouts for `multiprocessing` `Pool`-related code in recent PRs like scipygh-17777 and scipygh-17829 * nothing stands out in the build logs when I do a side-by-side diff vs. succeeding versions of the job, and the GHA job history seems to suggest the failure doesn't happen every time the CI is flushed, but perhaps more often lately * make a few cleanups here in attempt to fix - previous discussions like scipygh-11835 with MacOS Python 3.8 `multiprocessing` `Pool` hangs were complicated, but sometimes using `runtests.py` contributed to hangs b/c of `multiprocessing` import orders. So, try to use `pytest` directly instead to see if it helps. - we can simplify the Pythran config--there's only one job left in this file after the splitting with `meson`, and it is Python `3.8` - I've also extended the timeout limit a little bit, and since GHA MacOS runners have 3 cores I've tried using all 3 for the testsuite here because I once had the job pass on my fork during testing, but it took 66 minutes: #65 * I think there's still something a bit weird here, so it is a combination of measures that seemed to help a bit on my fork but perhaps long-term the removal of Python 3.8 support along with sunsetting `runtests.py` means that this mess may disappear before we need to dig much deeper [skip azp] [skip circle] [skip cirrus]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reference issue
Closes gh-16998
Supersedes gh-16999
What does this implement/fix?
gh-16998 reported that when a distribution that relies on the singleton RandomState is deepcopied (or pickled/unpickled, etc.), it always copies the random state, too. A consequence is that
np.random.seedno longer controls the random state. This PR documents that behavior.Additional information
This is my first commit created using PyCharm : P Thanks @tupui!