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

[Ilhan Polat]

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
> <https://numpy.org/doc/stable/reference/routines.fft.html#normalization>):
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20200629/6e3057ee/attachment.html>