[Numpy-discussion] Numpy FFT normalization options issue (addition of new option)

Ross Barnowski rossbar15 at gmail.com
Fri Jun 5 15:52:11 EDT 2020

On Thu, Jun 4, 2020 at 7:05 AM cvav <cv1038 at wildcats.unh.edu> wrote:

> Issue #16126: https://github.com/numpy/numpy/issues/16126
> PR #16476: https://github.com/numpy/numpy/pull/16476
> numpy.fft docs (v1.18):
> https://numpy.org/doc/1.18/reference/routines.fft.html
> Hello all,
> I was advised to write on the numpy mailing list, after this week's
> community meeting led to some general discussions on the normalization
> schemes used in the FFT functions.
> My post has to do with issue #16126, which asks for the addition of a new
> option for the "norm" argument for the FFT functions; "norm" controls the
> way the forward (direct) and backward (inverse) transforms are normalized,
> and the two currently supported options are "norm=None" (default) and
> "norm=ortho". The "ortho" option uses the orthonormal Fourier basis
> functions, which translates to both the forward and backward transforms
> being scaled by 1/sqrt(n), where n is the number of Fourier modes (and data
> points). The default "None" option scales the forward transform by 1
> (unscaled) and the backward by 1/n.
> The new added option, called for now "norm=inverse", is the exact opposite
> of the default option; i.e. it scales the forward transform by 1/n and the
> backward by 1. In terms of using the FFT for spectral methods or
> approximation problems, these are the three scaling schemes one encounters;
> the transform itself is the same, with only a constant factor being the
> difference. But having all three scaling options built in the fft and ifft
> functions makes the code cleaner and it's easier to stay consistent.
> I've submitted a PR for this change, and would be happy to get comments and
> feedback on the implementation and anything else that hasn't been
> considered. Thanks!
> Chris
> 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.

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.

Ross Barnowski

> --
> Sent from: http://numpy-discussion.10968.n7.nabble.com/
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200605/3b59863f/attachment-0001.html>

More information about the NumPy-Discussion mailing list