-
Notifications
You must be signed in to change notification settings - Fork 210
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
Correctness tests? #65
Comments
Given the (ahem) sparse nature of the example, the complete lack of any test cases and the fact that it won't compile out of the box on non SSE architectures (https://github.com/anthonix/ffts/blob/master/src/ffts_trig.c#L884) I'd say you have cause for concern. That said non-square may simply be an undocumented limitation. Albeit an unexpected one in what is very useful for image processing etc. |
I figured it out (wasted literally days to it)... So, this fixes the non-square issue I had. However, when using non power of two dimensions in the 2D case, it is still broken. In case one dimension is odd (2N+1), transpose segfaults, because it assumes that it can transpose nice blocks. |
Also figured the last problem out: 2D FFTS only works on sizes of multiples of 8 complex numbers. This definitely should be documented somewhere. |
I might be observing something similar for 1D FFTS. I'm trying to determine when the output of FFTS matches that of MATLAB with a basic real to complex FFT. If I pass an nfft which is a multiple of 8 (the first parameter of ffts_plan_1d), the result of FFTS comes out strangely different from MATLAB. For other values, FFTS matches MATLAB. I've been trying to debug a piece of my code for a few days now, which uses the following default sizes:
The output ends up wrong and totally different from similar examples in MATLAB and Python (using numpy + scipy). If I use an input signal size of 513 and nfft = 1026 (i.e. non multiples of 8), FFTS == MATLAB == numpy/scipy. edit: next thing I'll be verifying if this is related to memory alignment for sizes that are multiples of 8. |
also worth checking against https://github.com/linkotec/ffts as that fork seems to have had more input over the last few years than this repo. |
I compiled the above fork and still, using 1022 and 1026 produce correct results, and 1024 produces bad results. It also seems unrelated to memory alignment (I used the alignment code here: #55 (comment)) |
@sevagh can you share a minimal test example? I will try it here. |
Sure. Here's an example showing several similar tests with n = 1022, 1023, 1024, 1025 - all except 1024 have similar values: #include <iostream>
#include <complex>
#include <vector>
#include <numeric>
#include "ffts/ffts.h"
void print_fft(std::vector<float> &arr) {
int n = arr.size();
int nfft = 2*n;
ffts_plan_t *p = ffts_init_1d(nfft, FFTS_FORWARD);
std::vector<std::complex<float>> result(nfft);
// fill real input into first half of result complex array
for (int i = 0; i < n; ++i) {
result[i] = std::complex<float>(arr[i], 0.0);
}
// explicitly fill second half with zeros
std::fill(result.begin()+n, result.end(), std::complex<float>(0.0, 0.0));
// fft in-place
ffts_execute(p, result.data(), result.data());
std::cout << "fft result for n = " << n << ", nfft = " << nfft << ", first 8 entries" << std::endl;
for (std::size_t i = 0; i < 8; ++i) {
std::cout << result[i] << std::endl;
}
std::cout << std::endl;
std::cout << std::endl;
}
int
main(int argc, char **argv)
{
std::vector<float> test0(1022);
std::iota(test0.begin(), test0.end(), 1.0);
std::vector<float> test1(1023);
std::iota(test1.begin(), test1.end(), 1.0);
std::vector<float> test2(1024);
std::iota(test2.begin(), test2.end(), 1.0);
std::vector<float> test3(1025);
std::iota(test3.begin(), test3.end(), 1.0);
std::vector<float> test4(1025);
std::iota(test4.begin(), test4.end(), 1.0);
print_fft(test0);
print_fft(test1);
print_fft(test2);
print_fft(test3);
print_fft(test4);
return 0;
} Output:
MATLAB has values similar to 1022,1023,1025,1026. Seems like 1024 on FFTS is the outlier:
|
If I modify
|
Is ffts ever checked for correctness, because I'm getting highly suspicious about the correctness. Comparing results from FFTS and matlab, leads me to believe that FFTS is broken for 2D non-square transforms.
The text was updated successfully, but these errors were encountered: