I am not sure if I understand it correctly but why do they have to be about the virtual direction of the transform. This might not be the canonical way but reads quite nice to my subjective opinion.

fft(x, norm="by_N")

fft(x, norm="by_sqrt_N")

fft(x, norm=None) # Can even be "by_1" if OCD kicks in

ifft(x, norm="by_n") # just to place examples with small n

ifft(x, norm="by_sqrt_n")

ifft(x, norm=None)

Obviously, I'm assuming that these options are not typed every two minutes during the day. But then probably you have bigger problems than this.

Unrelated : This naming always ignites questions from people I'm teaching or assisting with FFTs. "norm" is already a well-defined concept applicable to any vector-concept. "normalize" is also a well-defined concept specific to FFTs. Calling it "norm" would not have been my option. Saving 5 characters doesn't justify the confusion in my opinion. But anyways just wanted to mention in case any deprecation is on the horizon. But of course the ship has sailed long ago.

On Sat, Jun 27, 2020 at 4:20 PM Sebastian Berg <sebastian@sipsolutions.net> wrote:

Hi all,

on the NumPy mailing list (and PR) it came up that CuPy would like to
the normalization in FFTs in the opposite way as the defaults. This is
for technical reasons on the GPU, but we need to add a new
`norm="something"` mode for it. And CuPy, numpy, and scipy should all
be happy with the choice.

The current favorits are:

* "forward" ("backward" could be added to be identical to default)
* "reversed"
* "inverse"

Currently, we scale the *inverse* transformation, instead of the direct
transformation. A nice property of the `norm` kwarg is that round-
tripping is defined if used always the same:

x ~= ifft(fft(x, norm=...), norm=...)

(assuming the lengths are good). So that disabling normalization
entirely loses the property.

If I read it correctly, "forward" is currently the crowd-favorite, and
we will probably go ahead with something in a few days. But
alternative proposals or opinions on which to choose are very welcome!

Cheers,

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