On Sat, 2020-06-27 at 17:47 +0200, Ilhan Polat wrote:
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.
I confess the direction notion confused me at first, it requires the step of realizing that this is about the pair of fft/ifft. OTOH, I am not if custom norm(alize) is actually used mainly in a context where you do both transforms. 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. 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... - Sebastian
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 twominutes 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.
Indeed, can't say I disagree, but likely not worth the the confusion of switching/having two options. - Sebastian
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
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev