[SciPy-Dev] New normalization option/kwarg for fft normalization

[Hanno Klemm]

As someone who uses FFTs a lot for filtering or applying operators in the spectral domain, I find the consistency of the FFT/IFFT pairs extremely important. I also have to say that I am not a big fan of the names for the normalisations that are currently discussed but I also don‘t have a better idea.

Therefore, mentioning in the docstring how these normalisations affect the round trip is a good idea from my point of view. 

Hanno

> On 29. Jun 2020, at 04:51, Ilhan Polat <ilhanpolat at gmail.com> wrote:
> 
> 
> I am a bit suspicious of the need for round-trip-equality for the majority of the users. For one, I hardly ever used them as a pair for the same object. So this idempotent requirement seems a bit of an occupational hazard to me. All users that will perform a one-way transform and be done with it, are now going to be thinking about a direction that they have nothing to do with. I don't see why IFFT comes into play in the docstring of FFT. These are exclusively separate transformations.
> 
> 
> 
> 
> 
>> On Mon, Jun 29, 2020 at 1:34 AM Eric Larson <larson.eric.d at gmail.com> wrote:
>>  
>>> On small argument against the "by_n" approach is that both `"ortho"`
>>> and `None` use the directional notion already implicitly.  Since below
>>> you would need the `ifft(x, norm="by_1")` to achieve the desired effect
>>> here as None will normalize the `ifft` by default.
>> 
>> One option would be to change the default None to an alias "inverse" to make it clearer. This could be done without a deprecation cycle.
>> 
>>> So using `by_n` or similar, works well, but may make a call without
>>> `norm` slightly more confusing (you may expect no normalization at all
>>> on the `ifft`)?  Not sure its a big argument, though...
>> 
>> To me the least ambiguous naming are:
>> 
>> 1. Related to the transforms themselves, as these have the most clearly understood usage and naming for most people in most FFT/IFFT contexts that I've seen; and
>> 2. Can be passed to both functions the same way to achieve round-trip equality (i.e., np.allclose(ifft(fft(x,norm=norm),norm=norm),x)).
>> 
>> People who want to do something weird like no normalization in either direction are not the ones that I think should be prioritized here, as they are the exception and not the rule (far rarer I'd expect). So I'd prefer that the naming reflect the generally desirable round-trip equality. This makes it easiest for people working with FFT and IFFT pairs (or even using FFT and thinking about Parseval's relation of the resulting frequency-domain data) to understand what's going on. For example this is a pretty clear docstring to me (as is NumPy's current one):
>> norm : {'forward', 'inverse', 'ortho', None}
>>     The normalization to apply during the FFT or IFFT, each of which will ensure
>>     round-trip numerical equivalence when the same value is passed to both forward
>>     and inverse transform functions:
>> 
>>     - "inverse" (default; same as None) will apply full normalization only during
>>       the IFFT (1/N); this follows the standard definition of the discrete Fourier
>>       transform and its inverse.
>>     - "forward" will apply full normalization only during the FFT (1/N).
>>     - "ortho" will apply half the normalization during the FFT and the IFFT
>>       (1/sqrt(N)), thereby ortho-normalizing the bases.
>> One could argue that "ortho" could equivalently be "split" or "half" or something, but it already seems clear enough about what it will do (and even why it's potentially useful).
>> 
>> My 2c,
>> Eric
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20200629/7d515aaf/attachment-0001.html>