[Numpy-discussion] NumPy Community Meeting Wednesday
Hi all, There will be a NumPy Community meeting Wednesday May 27th at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option)
Your approach sounds good to me. Thanks, Yu On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris 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 > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option)
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 NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
