For nfft<=3, this function computed k by converting infinity to int64.
For the last 4 years, 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? :man_shrugging:
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 here?)
For
nfft<=3, this function computedkby converting infinity to int64.For the last 4 years, this seemed to not cause any trouble, because
np.float64("inf").astype(int)yielded -9223372036854775808 and the loop did not run. However, with the currentmacos-14GitHub 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? :man_shrugging:
With this change
macos-14runners 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 here?)