Closed nilgoyette closed 1 year ago
The vector you posted here is symmetric around the middle element, not conjugate symmetric. This won't give you a real result. For example, since the second element is Complex::new(-3049261.861, 2288111.7098) I would expect the last element to be Complex::new(-3049261.861, -2288111.7098). Are you comparing with the right values?
For the data above, Numpy gives me this for the first five elements: 1152.6753875 +166290.37557857j 2160.10844305+138306.04022324j 3010.74789284 +98521.72931408j 2787.28305285 +84694.76667457j 2783.03673224 +79827.58606261j That's not what you get from rustfft, so there may be somethng strange here. Do you get the same result if you use the out-of-place transform?
@HEnquist Thank you for checking. You're right, I'm sorry, I used find & replace to format the list of complex numbers for github and I destroyed all negatives :| It's fixed now! I copied my code snippet from the first post and now it gives what I said.
Alright, then it's all clear. It's the normalization. Rustfft does not normalize the result, while the others do. See https://docs.rs/rustfft/latest/rustfft/#normalization Divide your result by 112 (the length) and you should have matching numbers.
Oh! This is good to know. I lost several hours debugging this hahaha. It was in the documentation. No excuse :)
Thank you!
Hi. I'm porting an application from C++ to Rust and I obtain strange results from
rustfft
.I have a vector
v
of 112 (nb_rows
) elements, already filled with complex data.This is working perfectly. I obtain the same results with NumPy and Eigen.
When I try to use
plan_fft_inverse
however...The first 5 elements look like that.
TBH, I don't know what the exact result should be, but I would have believed rustfft, NumPy and Eigen should be mostly identical ± epsilon. So I'm led to believe that rustfft has a bug.