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

[Gregory Lee]

Ilhan,

So are you suggesting that rather than using the same "backward" (or None),
"ortho", or "forward" argument in fft and ifft you would specify something
similar to the following?:

# normalize by 1/N on the inverse transform
y = fft(x, norm="1")  # or norm=None to preserve backwards-compatibility
x_roundtrip = ifft(y, norm="N")   # or norm=None to preserving
backwards-compatibility

# normalize by 1/N on the forward transform
y = fft(x, norm="N")
x_roundtrip = ifft(y, norm="1")

# normalize by 1/sqrt(N) on each
y = fft(x, norm="ortho")
x_roundtrip = ifft(y, norm="ortho")

Neal Becker suggested something like the above in the NumPy thread, but
with norm="full" to indicate normalization by 1/N

I like the "backward"/"ortho"/"forward" approach where the same kwarg is
used in both directions a little better, but agree that either approach has
its merits. It seems that we can maintain backwards compatibility either
way.


On Sun, Jun 28, 2020 at 10:50 PM 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
>> <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
>>
> _______________________________________________
> 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/e3ff013e/attachment.html>