>> 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
[email protected]
https://mail.python.org/mailman/listinfo/numpy-discussion
