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

Peter Bell peterbell10 at live.co.uk
Sun Jun 28 21:59:19 EDT 2020

>> Honestly, I don't find "forward" very informative.  There isn't any real convention on whether FFT of IFFT have any normalization.
>> To the best of my experience, either forward or inverse could be normalized by 1/N, or each normalized by 1/sqrt(N), or neither
>> could be normalized.  I will say my expertise is in signal processing and communications.
>> Perhaps
>> norm = {full, half, none} would be clearest to me.

>If I understand your point correctly and the discussion so far, the
>intention here is to use the keyword to denote the convention for an
>FFT-IFFT pair rather than just normalization in a single
>transformation (either FFT or IFFT).
>The idea being that calling ifft on the output of fft while using the
>same `norm` would be more or less identity. This would work for
>"half", but not for, say, "full". We need to come up with a name that
>specifies where normalization happens with regards to the
>forward-inverse pair.

For what it's worth, I'm not sure that norm referring to a pair of transforms was ever a conscious decision. The numpy issue that first proposed the norm argument was gh-2142 which references scipy.fftpack's discrete cosine transforms. However, fftpack's dct never applied a 1/N normalization factor in either direction. So, norm=None really did mean "no normalization". It was then carried over to NumPy with None instead meaning "default normalization".

Unfortunately, this means norm=None could easily be mistaken for "no normalization", and would make accepting norm="none" terribly confusing. To break this confusion, I think the documentation should refer to norm={"backward", "ortho", "forward"} where "backward" is a synonym for norm=None.

As an aside, the history with the dct makes it clear the choice was "ortho" and not "unitary" because the dct is a real transform.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200629/2fd43729/attachment-0001.html>

More information about the NumPy-Discussion mailing list