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

Andras Deak deak.andris at gmail.com
Sun Jun 28 18:14:39 EDT 2020


On Sun, Jun 28, 2020 at 9:37 PM Neal Becker <ndbecker2 at gmail.com> 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 <sebastian at sipsolutions.net> 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 at python.org
>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>> >
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion


More information about the NumPy-Discussion mailing list