<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 4, 2020 at 7:05 AM cvav <<a href="mailto:cv1038@wildcats.unh.edu">cv1038@wildcats.unh.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Issue #16126: <a href="https://github.com/numpy/numpy/issues/16126" rel="noreferrer" target="_blank">https://github.com/numpy/numpy/issues/16126</a><br>
PR #16476: <a href="https://github.com/numpy/numpy/pull/16476" rel="noreferrer" target="_blank">https://github.com/numpy/numpy/pull/16476</a><br>
numpy.fft docs (v1.18):<br>
<a href="https://numpy.org/doc/1.18/reference/routines.fft.html" rel="noreferrer" target="_blank">https://numpy.org/doc/1.18/reference/routines.fft.html</a><br>
<br>
Hello all, <br>
I was advised to write on the numpy mailing list, after this week's<br>
community meeting led to some general discussions on the normalization<br>
schemes used in the FFT functions.<br>
<br>
My post has to do with issue #16126, which asks for the addition of a new<br>
option for the "norm" argument for the FFT functions; "norm" controls the<br>
way the forward (direct) and backward (inverse) transforms are normalized,<br>
and the two currently supported options are "norm=None" (default) and<br>
"norm=ortho". The "ortho" option uses the orthonormal Fourier basis<br>
functions, which translates to both the forward and backward transforms<br>
being scaled by 1/sqrt(n), where n is the number of Fourier modes (and data<br>
points). The default "None" option scales the forward transform by 1<br>
(unscaled) and the backward by 1/n. <br>
<br>
The new added option, called for now "norm=inverse", is the exact opposite<br>
of the default option; i.e. it scales the forward transform by 1/n and the<br>
backward by 1. In terms of using the FFT for spectral methods or<br>
approximation problems, these are the three scaling schemes one encounters;<br>
the transform itself is the same, with only a constant factor being the<br>
difference. But having all three scaling options built in the fft and ifft<br>
functions makes the code cleaner and it's easier to stay consistent.<br>
<br>
I've submitted a PR for this change, and would be happy to get comments and<br>
feedback on the implementation and anything else that hasn't been<br>
considered. Thanks!<br>
<br>
Chris<br>
<br>
</blockquote><div>This seems reasonable; in fact the addition of this normalization option was discussed in #2142, but there doesn't seem to have been a compelling use-case at that time.</div><div><br></div><div>One potential issue that stood out to me was the name of the new keyword option. At face value, "inverse" seems like a poor choice given the established use of the term in Fourier analysis. For example, one might expect `norm="inverse"` to mean that scaling is applied to the ifft, when this is actually the current default. <br></div><div><br></div><div>Ross Barnowski<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
--<br>
Sent from: <a href="http://numpy-discussion.10968.n7.nabble.com/" rel="noreferrer" target="_blank">http://numpy-discussion.10968.n7.nabble.com/</a><br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div>