I think it's also important to get the thoughts of the SciPy community on this topic so that we avoid divergence between numpy.fft and scipy.fft. I would recommend sending this discussion to the scipy mailing list as well.
~Ross On Tue, Jun 23, 2020 at 4:11 PM Feng Yu <[email protected]> wrote: > Your approach sounds good to me. > > Thanks, > > Yu > > On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris <[email protected]> > wrote: > >> Chris Vavaliaris wrote >> > Hello, >> > >> > - my first reaction would be that the less argument names we change at a >> > time the better, so that we don't confuse people or cause codes written >> > with >> > previous NumPy versions to break. Personally I always think of "ortho" >> as >> > "orthonormal", which immediately brings "unit norm" to mind, but I have >> no >> > problem whatsoever with changing its name to "unitary" or maybe "unit", >> > which I'd probably choose if we were writing the routines from scratch. >> > >> > - In terms of the "inverse" name option, I do believe that it'd be a >> > confusing choice since "inverse" is used to describe the inverse FFT; if >> > we >> > choose to stick with a name that's based on the fact that this scaling >> is >> > opposite to the "norm=None" option, then I'd suggest "norm=opposite" as >> a >> > better choice. However, following Ross' comment, I think we could >> choose a >> > name based on the fact that the forward transform is now scaled by `n`, >> > instead of the backward one as in the default "norm=None". In this case, >> > I'd >> > suggest "norm=forward", which we can also nicely abbreviate to the >> > 4-character form "norm=forw" if desirable. >> > >> > Chris >> > >> > >> > Feng Yu wrote >> >> Hi, >> >> >> >> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as >> 'unitary'. >> >> Since we are in general working with complex numbers, I do suggest >> >> unitary >> >> over ortho. >> >> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) >> and ( >> >> >> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT) >> >> >> >> 2. I share Chris's concern about 'inverse', but I could not come up >> with >> >> a >> >> nice name. >> >> >> >> 3. Now that we are at this, should we also describe the corresponding >> >> continuum limit of FFT and iFFT in the documentation? >> >> >> >> A paragraph doing so could potentially also help people diagnose some >> of >> >> the normalization factor errors. I assumed it is common that one needs >> to >> >> translate a CFT into DFT when coding a paper up, and the correct >> >> compensation to the normalization factors will surface if one does the >> >> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the >> >> variable >> >> is angular frequency, but it's been a while since I did that last time. >> >> >> >> - Yu >> >> >> >> NumPy-Discussion mailing list >> > >> >> NumPy-Discussion@ >> > >> >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> > >> > >> > >> > >> > -- >> > Sent from: http://numpy-discussion.10968.n7.nabble.com/ >> > _______________________________________________ >> > NumPy-Discussion mailing list >> >> > NumPy-Discussion@ >> >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> Hello all, >> the discussion on this topic has been stagnant for the past couple of >> weeks, >> so I just wanted to ask if anyone has any alternative names for the new >> normalization option that would like to share. >> >> If not, I'd suggest that we move on with "norm=forward", which seems to >> be a >> more straightforward choice than the "norm=inverse" naming alternative. I >> can wait a couple of days for possible new recommendations to be >> submitted, >> and will then recommit to the open PR to account for the new kwarg name. >> >> In terms of the name for the "norm=ortho" option, I suggest that we keep >> it >> as is for now so that we don't introduce two API changes at once. If >> desired, we can discuss it separately and open a new PR introducing a name >> such as "norm=unitary" or "unit" as recommended in previous messages. I'm >> happy to handle that if you think it'd be a useful change. >> >> Chris >> >> >> >> >> >> -- >> Sent from: http://numpy-discussion.10968.n7.nabble.com/ >> _______________________________________________ >> NumPy-Discussion mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] https://mail.python.org/mailman/listinfo/numpy-discussion
