-
Notifications
You must be signed in to change notification settings - Fork 62
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
Question about Normalization of Foward Fast Fourier Transform #465
Comments
@Ameyanagi Good question, we should check this carefully.
and then use these (at xraylarch/larch/xafs/xafsft.py Line 321 in 65b23e7
and xraylarch/larch/xafs/xafsft.py Line 346 in 65b23e7
We're using |
@newville
numpy fft is also the same. |
@Ameyanagi Thanks -- that suggests "no normalization", and then we do the normalization in |
@newville By the way,I currently have a m1 Macbook, in which, it falls back to scipy.
|
@newville |
@Ameyanagi Ok, that makes sense. Still, I think it is worth double-checking that we're doing the scaling correctly (or at least consistently). I haven't had a chance to dig into that, but I'll try to get to it soon. |
@newville
After double-checking the functions, I would suggest changing descriptions of the normalization factors in the documentation. Do you know any literature in EXAFS that mentions the normalization factors of FFT? It might be worth, summarizing how the R space of each software scale within each other, so that we don't get confused about the plots obtained by different software. |
@newville
I have a question about the Normalization of FFT in larch.
I was reading the Documentation and saw that normalization is treated as symmetrical, which means it is divided by the 1/sqrt(N).
However, the current implementation seems to be using 1 for forward FFT. (at least for scipy.fftpack.fft)
Is this intentional behavior? I was confused about what is the standard for normalizing the amplitudes in EXAFS analysis.
The text was updated successfully, but these errors were encountered: