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
MAINT, TST: test failures against NumPy main #20062
Comments
@tylerjereddy - I suspect this is because numpy now doesn't automatically upcast to double any more. From the failures, it looks like integer input is given to the FFT routines (seeing things like At least, I hope it is as simple as that! I obviously don't want to cause undue problems! |
thanks! |
I would hope it is precision change, but the default lookup should only allow float64 loops for default integers (32bit ints are not "safely" cast to float32, only float64). Or did we add a non-default loop selection? |
Yes, that is worrying. Yet, the integer input seems to correspond to Looking at the tests in
it seems more obvious: the numpy fft is just doing the calculation at a different precision that the internal call; I think that should be EDIT: or maybe |
* Fixes scipy#20062 * for 2/3 of the problem tests I was able to adopt the philosophy of "let's keep the expected value the same; we don't really care what NumPy is doing as long as the expected value in the test is the same as before"; so, we compensate for the casting changes in NumPy by generating the expected value with a more explicit cast * for `test_fourier_shift_complex01` that would be more surgery though--this one is a real mess--it calls NumPy FFT functionality twice before the SciPy function under test, then feeds that input to the SciPy function under test, then calls NumPy FFT functionality twice on the output of the SciPy function under test; here, I dropped the lower-precision pass-through test precision expectations, because we can't lean on NumPy to automatically preserve as much precision here anymore; a stricter view on preserving the essence of this test might be to either hardcode the expected value in the lower-precision dtype case, or carefully craft it with NumPy wider dtype while not feeding the wider dtype to the SciPy function under test [skip cirrus] [skip circle]
Details of test failures
It is all related to FFT stuff. Bisected on x86_64 Linux to:
cc @mhvk @seberg just in case the shims aren't exclusively needed on our end (that I'm not sure of just yet)
The text was updated successfully, but these errors were encountered: