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
BUG: behavioral change of numpy.fft.rfft with numpy 2.x #26349
Comments
There's an undocumented change in mumpy 2.x, see numpy/numpy#26349
@mhvk is maybe another one of those "FFT seems simple but is not?" off-by-one errors. I think the SciPy fft returns the same as NumPy used to here, so it seems plausible (didn't try to understand yet what is going on, maybe it makes sense). |
Is this intended behavior? |
@whym1here, no, it is a bug. When The equivalent calculation using
|
I have a possible fix in #26354. |
There's an over-copy of the 5th input element when only a shorter length fft was required. >>> np.fft.rfft(np.array([0,1,2,3]), 4)
array([ 6.+0.j, -2.+2.j, -2.+0.j])
>>> np.fft.rfft(np.array([0,1,2,3,123]), 4)
array([ 6. +0.j, -2. +2.j, -2.+123.j])
>>> np.fft.rfft(np.array([0,1,2,3,123])[:4], 4)
array([ 6.+0.j, -2.+2.j, -2.+0.j]) |
Merci / thanks!
|
There's an undocumented change in mumpy 2.x, see numpy/numpy#26349
Describe the issue:
With numpy 2.x:
with numpy 1.26.4:
that's a notable output difference, maybe introduced by the vectorized form of pocketfft?
Reproduce the code example:
Error message:
No response
Python and NumPy Versions:
2.1.0.dev0+git20240423.ef5f10d
3.12.2 (main, Feb 21 2024, 00:00:00) [GCC 13.2.1 20231205 (Red Hat 13.2.1-6)]
Runtime Environment:
No response
Context for the issue:
Difference found while porting pythran to numpy 2.x, as pythran mimics the 'legacy' behavior.
I'm unsure whether the new behavior is intended or not, at least it's not documented in the git log as far as I can tell (?)
The text was updated successfully, but these errors were encountered: