-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Frequent timeouts for mac (3.11)
workflow runs
#1383
Labels
Comments
will have a look 👍🏼 |
dweindl
added a commit
to dweindl/pyPESTO
that referenced
this issue
May 3, 2024
Should prevent unclear timeouts ICB-DCM#1383.
dweindl
added a commit
that referenced
this issue
May 3, 2024
Prevents unclear timeouts that occur with `macos-14-arm64` (see #1383).
dweindl
added a commit
to dweindl/pyPESTO
that referenced
this issue
May 3, 2024
For `nfft<=3`, this function computed `nk` by converting infinity to int64. For the last [4 years](ICB-DCM@fdbacb4), this seemed to not cause any trouble, because `np.float64("inf").astype(int)` yielded -9223372036854775808 and the loop did not run. However, with the current macos-14 GitHub runner, this yields 9223372036854775807, and accordingly, to rather long computation times (this is what caused ICB-DCM#1383). I am not really sure what caused this change. macos-12 vs macos-14, arm64 vs x86, ...? all should be IEEE 754-compliant. Maybe some different integer type? 🤷♂️ With this change macos-14 yields the same results as the other runners. However, I am not familar with computing power spectral density and I don't know if this is indeed what should happen. It would be great if somebody more familiar with that topic could double-check. (Also, can't we use [scipy.signal.welch](https://docs.scipy.org/doc/scipy/reference/generated/scipy.signal.welch.html#scipy.signal.welch) here?)
I take that back. This, as well as the timeouts in general, was a consequence of the issue addressed in #1388. |
dweindl
added a commit
that referenced
this issue
May 4, 2024
For `nfft<=3`, this function computed `k` by converting infinity to int64. For the last [4 years](fdbacb4), this seemed to not cause any trouble, because `np.float64("inf").astype(int)` yielded -9223372036854775808 and the loop did not run. However, with the current `macos-14` GitHub runner, this yields 9223372036854775807, and accordingly, rather long computation times (this is what caused #1383). I am not really sure what caused this change. macos-12 vs macos-14, arm64 vs x86, ...? all should be IEEE 754-compliant. Maybe some different integer type? 🤷♂️ With this change `macos-14` runners yield the same results as the other runners. However, I am not familiar with computing power spectral density and I don't know if this is indeed what should happen. It would be great if somebody more familiar with that topic could double-check. (Also, can't we use [scipy.signal.welch](https://docs.scipy.org/doc/scipy/reference/generated/scipy.signal.welch.html#scipy.signal.welch) here?)
I think this should be fixed right now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are currently frequent timeouts for
mac (3.11)
workflow runs.The by far slowest test is:
239.30s call test/sample/test_sample.py::test_thermodynamic_integration
Can this be reduced to <1min?
The text was updated successfully, but these errors were encountered: