Re: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option)
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.
Thanks,
Neal
On Sat, Jun 27, 2020 at 10:40 AM Sebastian Berg
wrote:
> On Fri, 2020-06-26 at 21:53 -0700, leofang wrote:
> > Hi all,
> >
> >
> > Since I brought this issue from CuPy to Numpy, I'd like to see a
> > decision
> > made sooner than later so that downstream libraries like SciPy and
> > CuPy can
> > act accordingly. I think norm='forward' is fine. If there're still
> > people
> > unhappy with it after my reply, I'd suggest norm='reverse'. It has
> > the same
> > meaning, but is less confusing (than 'inverse' or other choices on
> > the
> > table) to me.
> >
>
> I expect "forward" is good (if I misread something please correct me),
> and I think we can go ahead with it, sorry for the delay. However, I
> have send an email to scipy-dev, since we should give them at least a
> heads-up, and if you do not mind, I would wait a few days to actually
> merge (although we can also simply reverse, as long as CuPy does not
> have a release with it).
>
> It might be nice to expand the kwarg docs slightly with a sentence for
> each normalization mode? Refering to `np.fft` docs is good, but if we
> can squeeze in a short refresher and refer there for details/formula it
> would be nicer.
> I feel "forward" is very intuitive, but only after pointing out that it
> is related to whether the fft or ifft has the normalization factor.
>
> Cheers,
>
> Sebastian
>
>
> >
> > Best,
> > Leo
> >
> >
> >
> > --
> > 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
>
--
*Those who don't understand recursion are doomed to repeat it*
___
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)
On Sun, Jun 28, 2020 at 9:37 PM Neal Becker 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.
Does this make sense, considering your point?
András
>
> Thanks,
> Neal
>
> On Sat, Jun 27, 2020 at 10:40 AM Sebastian Berg
> wrote:
>>
>> On Fri, 2020-06-26 at 21:53 -0700, leofang wrote:
>> > Hi all,
>> >
>> >
>> > Since I brought this issue from CuPy to Numpy, I'd like to see a
>> > decision
>> > made sooner than later so that downstream libraries like SciPy and
>> > CuPy can
>> > act accordingly. I think norm='forward' is fine. If there're still
>> > people
>> > unhappy with it after my reply, I'd suggest norm='reverse'. It has
>> > the same
>> > meaning, but is less confusing (than 'inverse' or other choices on
>> > the
>> > table) to me.
>> >
>>
>> I expect "forward" is good (if I misread something please correct me),
>> and I think we can go ahead with it, sorry for the delay. However, I
>> have send an email to scipy-dev, since we should give them at least a
>> heads-up, and if you do not mind, I would wait a few days to actually
>> merge (although we can also simply reverse, as long as CuPy does not
>> have a release with it).
>>
>> It might be nice to expand the kwarg docs slightly with a sentence for
>> each normalization mode? Refering to `np.fft` docs is good, but if we
>> can squeeze in a short refresher and refer there for details/formula it
>> would be nicer.
>> I feel "forward" is very intuitive, but only after pointing out that it
>> is related to whether the fft or ifft has the normalization factor.
>>
>> Cheers,
>>
>> Sebastian
>>
>>
>> >
>> > Best,
>> > Leo
>> >
>> >
>> >
>> > --
>> > 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
>
>
>
> --
> Those who don't understand recursion are doomed to repeat it
> ___
> 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)
>> 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@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
