Closed ChristophWWagner closed 1 year ago
Update: Bluestein alone is not fully responsible for the trouble, since for small orders it seems to still work:
>>> fm.Fourier(127)[...] - fm.Fourier(127, optimize=False)[...]
array([[0.+0.j, 0.+0.j, 0.+0.j, ..., 0.+0.j, 0.+0.j, 0.+0.j],
[0.+0.j, 0.+0.j, 0.+0.j, ..., 0.+0.j, 0.+0.j, 0.+0.j],
[0.+0.j, 0.+0.j, 0.+0.j, ..., 0.+0.j, 0.+0.j, 0.+0.j],
...,
[0.+0.j, 0.+0.j, 0.+0.j, ..., 0.+0.j, 0.+0.j, 0.+0.j],
[0.+0.j, 0.+0.j, 0.+0.j, ..., 0.+0.j, 0.+0.j, 0.+0.j],
[0.+0.j, 0.+0.j, 0.+0.j, ..., 0.+0.j, 0.+0.j, 0.+0.j]])
>>> fm.Fourier(127, optimize=False)._numL
0
>>> fm.Fourier(127, optimize=True)._numL
256
>>> N = 127; np.linalg.norm(fm.Fourier(N)[...] - fm.Fourier(N, optimize=False)[...])
0.0
>>> N = 191; np.linalg.norm(fm.Fourier(N)[...] - fm.Fourier(N, optimize=False)[...])
0.0
>>> N = 3011; np.linalg.norm(fm.Fourier(N)[...] - fm.Fourier(N, optimize=False)[...])
0.0
>>> N = 127*7; np.linalg.norm(fm.Fourier(N)[...] - fm.Fourier(N, optimize=False)[...])
0.0
The previous update is misleading as it falls victim to the implicit overriding of the [...]
operator by the internal override in ._getArray()
(see https://github.com/EMS-TU-Ilmenau/fastmat/blob/f0e3fe95a619366c6f61e9af1ad360683b6b9398/fastmat/Fourier.pyx#L165)
It seems to actually fail also for the smaller values (127, 191, 3011 included, 127*7 does not trigger Bluestein)
Good news, everyone! Looks like reverting #d22813f0 resolves the error. The suggested fix is the following: 1) make sure the tests actually cover a Bluestein case 2) Fix the underlying issue of #d22813f0. Upon first glance for a test case of 127 there seems to be a mismatch of one or multiples factors-of-two
There seems to be a serious bug with the Bluestein implementation of the Fourier class.
MWE:
The problem also occurs for even Fourier orders:
For "simpler" prime factorizations of N, the problem does not persist:
Checking whether Bluestein is invoked yields:
In conclusion, the problem occurs only when Bluestein is involved.
Next steps