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

Sebastian Berg sebastian at sipsolutions.net
Sun Jul 12 15:46:51 EDT 2020


Just a heads-up.  As I think the discussion seemed to settled on
"backwards" (default, identical to None), "forward" and the existing
"ortho".

Thus "forward" and "backward" are now new valid values for the `norm`
keyword argument to the fft functions in NumPy. (see 
https://github.com/numpy/numpy/pull/16476)

- Sebastian


On Mon, 2020-06-29 at 01:59 +0000, Peter Bell wrote:
> > > 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.
> 
> -Peter
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200712/4b8839a8/attachment.sig>


More information about the NumPy-Discussion mailing list