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

[Sebastian Berg]

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 at 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 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20200627/027b2c03/attachment.sig>