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

[Feng Yu]

Your approach sounds good to me.

Thanks,

Yu

On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris <cv1038 at wildcats.unh.edu>
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 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/20200623/4ac98e02/attachment.html>