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@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@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@python.org
https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@python.org
https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@python.org
https://mail.python.org/mailman/listinfo/scipy-dev