Numpy FFT normalization options issue (addition of new option)

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Numpy FFT normalization options issue (addition of new option)

Chris Vavaliaris
Issue #16126: https://github.com/numpy/numpy/issues/16126
PR #16476: https://github.com/numpy/numpy/pull/16476
numpy.fft docs (v1.18):
https://numpy.org/doc/1.18/reference/routines.fft.html

Hello all,
I was advised to write on the numpy mailing list, after this week's
community meeting led to some general discussions on the normalization
schemes used in the FFT functions.

My post has to do with issue #16126, which asks for the addition of a new
option for the "norm" argument for the FFT functions; "norm" controls the
way the forward (direct) and backward (inverse) transforms are normalized,
and the two currently supported options are "norm=None" (default) and
"norm=ortho". The "ortho" option uses the orthonormal Fourier basis
functions, which translates to both the forward and backward transforms
being scaled by 1/sqrt(n), where n is the number of Fourier modes (and data
points). The default "None" option scales the forward transform by 1
(unscaled) and the backward by 1/n.

The new added option, called for now "norm=inverse", is the exact opposite
of the default option; i.e. it scales the forward transform by 1/n and the
backward by 1. In terms of using the FFT for spectral methods or
approximation problems, these are the three scaling schemes one encounters;
the transform itself is the same, with only a constant factor being the
difference. But having all three scaling options built in the fft and ifft
functions makes the code cleaner and it's easier to stay consistent.

I've submitted a PR for this change, and would be happy to get comments and
feedback on the implementation and anything else that hasn't been
considered. Thanks!

Chris



--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Ross Barnowski


On Thu, Jun 4, 2020 at 7:05 AM cvav <[hidden email]> wrote:
Issue #16126: https://github.com/numpy/numpy/issues/16126
PR #16476: https://github.com/numpy/numpy/pull/16476
numpy.fft docs (v1.18):
https://numpy.org/doc/1.18/reference/routines.fft.html

Hello all,
I was advised to write on the numpy mailing list, after this week's
community meeting led to some general discussions on the normalization
schemes used in the FFT functions.

My post has to do with issue #16126, which asks for the addition of a new
option for the "norm" argument for the FFT functions; "norm" controls the
way the forward (direct) and backward (inverse) transforms are normalized,
and the two currently supported options are "norm=None" (default) and
"norm=ortho". The "ortho" option uses the orthonormal Fourier basis
functions, which translates to both the forward and backward transforms
being scaled by 1/sqrt(n), where n is the number of Fourier modes (and data
points). The default "None" option scales the forward transform by 1
(unscaled) and the backward by 1/n.

The new added option, called for now "norm=inverse", is the exact opposite
of the default option; i.e. it scales the forward transform by 1/n and the
backward by 1. In terms of using the FFT for spectral methods or
approximation problems, these are the three scaling schemes one encounters;
the transform itself is the same, with only a constant factor being the
difference. But having all three scaling options built in the fft and ifft
functions makes the code cleaner and it's easier to stay consistent.

I've submitted a PR for this change, and would be happy to get comments and
feedback on the implementation and anything else that hasn't been
considered. Thanks!

Chris

This seems reasonable; in fact the addition of this normalization option was discussed in #2142, but there doesn't seem to have been a compelling use-case at that time.

One potential issue that stood out to me was the name of the new keyword option. At face value, "inverse" seems like a poor choice given the established use of the term in Fourier analysis. For example, one might expect `norm="inverse"` to mean that scaling is applied to the ifft, when this is actually the current default.

Ross Barnowski

--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Chris Vavaliaris
Ross Barnowski wrote
> One potential issue that stood out to me was the name of the new keyword
> option. At face value, "inverse" seems like a poor choice given the
> established use of the term in Fourier analysis. For example, one might
> expect `norm="inverse"` to mean that scaling is applied to the ifft, when
> this is actually the current default.

Yes that's true, the keyword argument name "inverse" is certainly something
I don't feel sure about. It'd be nice if everyone interested could suggest
names that make sense to them and what's their rationale behind them, so
that we pick something that's as self explanatory as possible.

My thinking was to indicate that it's the opposite scaling to the default
option "None", so maybe something like "opposite" or "reversed" could be
other choices. Otherwise, we can find something that directly describes the
scaling and not its relationship to the default option.  

Chris



--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Feng Yu
Hi,

1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'. Since we are in general working with complex numbers, I do suggest unitary over ortho.

2. I share Chris's concern about 'inverse', but I could not come up with a nice name.

3. Now that we are at this, should we also describe the corresponding continuum limit of FFT and iFFT in the documentation?

A paragraph doing so could potentially also help people diagnose some of the normalization factor errors. I assumed it is common that one needs to translate a CFT into DFT when coding a paper up, and the correct compensation to the normalization factors will surface if one does the math. -- I had the impression 1 / N corresponds to 1 / 2pi if the variable is angular frequency, but it's been a while since I did that last time.

- Yu

On Fri, Jun 5, 2020 at 1:16 PM cvav <[hidden email]> wrote:
Ross Barnowski wrote
> One potential issue that stood out to me was the name of the new keyword
> option. At face value, "inverse" seems like a poor choice given the
> established use of the term in Fourier analysis. For example, one might
> expect `norm="inverse"` to mean that scaling is applied to the ifft, when
> this is actually the current default.

Yes that's true, the keyword argument name "inverse" is certainly something
I don't feel sure about. It'd be nice if everyone interested could suggest
names that make sense to them and what's their rationale behind them, so
that we pick something that's as self explanatory as possible.

My thinking was to indicate that it's the opposite scaling to the default
option "None", so maybe something like "opposite" or "reversed" could be
other choices. Otherwise, we can find something that directly describes the
scaling and not its relationship to the default option.   

Chris



--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Chris Vavaliaris
Hello,

- my first reaction would be that the less argument names we change at a
time the better, so that we don't confuse people or cause codes written with
previous NumPy versions to break. Personally I always think of "ortho" as
"orthonormal", which immediately brings "unit norm" to mind, but I have no
problem whatsoever with changing its name to "unitary" or maybe "unit",
which I'd probably choose if we were writing the routines from scratch.

- In terms of the "inverse" name option, I do believe that it'd be a
confusing choice since "inverse" is used to describe the inverse FFT; if we
choose to stick with a name that's based on the fact that this scaling is
opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a
better choice. However, following Ross' comment, I think we could choose a
name based on the fact that the forward transform is now scaled by `n`,
instead of the backward one as in the default "norm=None". In this case, I'd
suggest "norm=forward", which we can also nicely abbreviate to the
4-character form "norm=forw" if desirable.

Chris


Feng Yu wrote

> Hi,
>
> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'.
> Since we are in general working with complex numbers, I do suggest unitary
> over ortho.
> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) and (
> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT)
>
> 2. I share Chris's concern about 'inverse', but I could not come up with a
> nice name.
>
> 3. Now that we are at this, should we also describe the corresponding
> continuum limit of FFT and iFFT in the documentation?
>
> A paragraph doing so could potentially also help people diagnose some of
> the normalization factor errors. I assumed it is common that one needs to
> translate a CFT into DFT when coding a paper up, and the correct
> compensation to the normalization factors will surface if one does the
> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the variable
> is angular frequency, but it's been a while since I did that last time.
>
> - Yu
>
> NumPy-Discussion mailing list

> NumPy-Discussion@

> https://mail.python.org/mailman/listinfo/numpy-discussion





--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Chris Vavaliaris
Chris Vavaliaris wrote

> Hello,
>
> - my first reaction would be that the less argument names we change at a
> time the better, so that we don't confuse people or cause codes written
> with
> previous NumPy versions to break. Personally I always think of "ortho" as
> "orthonormal", which immediately brings "unit norm" to mind, but I have no
> problem whatsoever with changing its name to "unitary" or maybe "unit",
> which I'd probably choose if we were writing the routines from scratch.
>
> - In terms of the "inverse" name option, I do believe that it'd be a
> confusing choice since "inverse" is used to describe the inverse FFT; if
> we
> choose to stick with a name that's based on the fact that this scaling is
> opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a
> better choice. However, following Ross' comment, I think we could choose a
> name based on the fact that the forward transform is now scaled by `n`,
> instead of the backward one as in the default "norm=None". In this case,
> I'd
> suggest "norm=forward", which we can also nicely abbreviate to the
> 4-character form "norm=forw" if desirable.
>
> Chris
>
>
> Feng Yu wrote
>> Hi,
>>
>> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'.
>> Since we are in general working with complex numbers, I do suggest
>> unitary
>> over ortho.
>> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) and (
>> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT)
>>
>> 2. I share Chris's concern about 'inverse', but I could not come up with
>> a
>> nice name.
>>
>> 3. Now that we are at this, should we also describe the corresponding
>> continuum limit of FFT and iFFT in the documentation?
>>
>> A paragraph doing so could potentially also help people diagnose some of
>> the normalization factor errors. I assumed it is common that one needs to
>> translate a CFT into DFT when coding a paper up, and the correct
>> compensation to the normalization factors will surface if one does the
>> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the
>> variable
>> is angular frequency, but it's been a while since I did that last time.
>>
>> - Yu
>>
>> NumPy-Discussion mailing list
>
>> NumPy-Discussion@
>
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
>
>
>
> --
> Sent from: http://numpy-discussion.10968.n7.nabble.com/
> _______________________________________________
> NumPy-Discussion mailing list

> NumPy-Discussion@

> https://mail.python.org/mailman/listinfo/numpy-discussion

Hello all,
the discussion on this topic has been stagnant for the past couple of weeks,
so I just wanted to ask if anyone has any alternative names for the new
normalization option that would like to share.

If not, I'd suggest that we move on with "norm=forward", which seems to be a
more straightforward choice than the "norm=inverse" naming alternative. I
can wait a couple of days for possible new recommendations to be submitted,
and will then recommit to the open PR to account for the new kwarg name.

In terms of the name for the "norm=ortho" option, I suggest that we keep it
as is for now so that we don't introduce two API changes at once. If
desired, we can discuss it separately and open a new PR introducing a name
such as "norm=unitary" or "unit" as recommended in previous messages. I'm
happy to handle that if you think it'd be a useful change.

Chris





--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Feng Yu
Your approach sounds good to me.

Thanks,

Yu

On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris <[hidden email]> wrote:
Chris Vavaliaris wrote
> Hello,
>
> - my first reaction would be that the less argument names we change at a
> time the better, so that we don't confuse people or cause codes written
> with
> previous NumPy versions to break. Personally I always think of "ortho" as
> "orthonormal", which immediately brings "unit norm" to mind, but I have no
> problem whatsoever with changing its name to "unitary" or maybe "unit",
> which I'd probably choose if we were writing the routines from scratch.
>
> - In terms of the "inverse" name option, I do believe that it'd be a
> confusing choice since "inverse" is used to describe the inverse FFT; if
> we
> choose to stick with a name that's based on the fact that this scaling is
> opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a
> better choice. However, following Ross' comment, I think we could choose a
> name based on the fact that the forward transform is now scaled by `n`,
> instead of the backward one as in the default "norm=None". In this case,
> I'd
> suggest "norm=forward", which we can also nicely abbreviate to the
> 4-character form "norm=forw" if desirable.
>
> Chris
>
>
> Feng Yu wrote
>> Hi,
>>
>> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'.
>> Since we are in general working with complex numbers, I do suggest
>> unitary
>> over ortho.
>> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) and (
>> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT)
>>
>> 2. I share Chris's concern about 'inverse', but I could not come up with
>> a
>> nice name.
>>
>> 3. Now that we are at this, should we also describe the corresponding
>> continuum limit of FFT and iFFT in the documentation?
>>
>> A paragraph doing so could potentially also help people diagnose some of
>> the normalization factor errors. I assumed it is common that one needs to
>> translate a CFT into DFT when coding a paper up, and the correct
>> compensation to the normalization factors will surface if one does the
>> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the
>> variable
>> is angular frequency, but it's been a while since I did that last time.
>>
>> - Yu
>>
>> NumPy-Discussion mailing list
>
>> NumPy-Discussion@
>
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
>
>
>
> --
> Sent from: http://numpy-discussion.10968.n7.nabble.com/
> _______________________________________________
> NumPy-Discussion mailing list

> NumPy-Discussion@

> https://mail.python.org/mailman/listinfo/numpy-discussion

Hello all,
the discussion on this topic has been stagnant for the past couple of weeks,
so I just wanted to ask if anyone has any alternative names for the new
normalization option that would like to share.

If not, I'd suggest that we move on with "norm=forward", which seems to be a
more straightforward choice than the "norm=inverse" naming alternative. I
can wait a couple of days for possible new recommendations to be submitted,
and will then recommit to the open PR to account for the new kwarg name.

In terms of the name for the "norm=ortho" option, I suggest that we keep it
as is for now so that we don't introduce two API changes at once. If
desired, we can discuss it separately and open a new PR introducing a name
such as "norm=unitary" or "unit" as recommended in previous messages. I'm
happy to handle that if you think it'd be a useful change.

Chris





--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Ross Barnowski
I think it's also important to get the thoughts of the SciPy community on this topic so that we avoid divergence between numpy.fft and scipy.fft. I would recommend sending this discussion to the scipy mailing list as well.

~Ross

On Tue, Jun 23, 2020 at 4:11 PM Feng Yu <[hidden email]> wrote:
Your approach sounds good to me.

Thanks,

Yu

On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris <[hidden email]> wrote:
Chris Vavaliaris wrote
> Hello,
>
> - my first reaction would be that the less argument names we change at a
> time the better, so that we don't confuse people or cause codes written
> with
> previous NumPy versions to break. Personally I always think of "ortho" as
> "orthonormal", which immediately brings "unit norm" to mind, but I have no
> problem whatsoever with changing its name to "unitary" or maybe "unit",
> which I'd probably choose if we were writing the routines from scratch.
>
> - In terms of the "inverse" name option, I do believe that it'd be a
> confusing choice since "inverse" is used to describe the inverse FFT; if
> we
> choose to stick with a name that's based on the fact that this scaling is
> opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a
> better choice. However, following Ross' comment, I think we could choose a
> name based on the fact that the forward transform is now scaled by `n`,
> instead of the backward one as in the default "norm=None". In this case,
> I'd
> suggest "norm=forward", which we can also nicely abbreviate to the
> 4-character form "norm=forw" if desirable.
>
> Chris
>
>
> Feng Yu wrote
>> Hi,
>>
>> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'.
>> Since we are in general working with complex numbers, I do suggest
>> unitary
>> over ortho.
>> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) and (
>> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT)
>>
>> 2. I share Chris's concern about 'inverse', but I could not come up with
>> a
>> nice name.
>>
>> 3. Now that we are at this, should we also describe the corresponding
>> continuum limit of FFT and iFFT in the documentation?
>>
>> A paragraph doing so could potentially also help people diagnose some of
>> the normalization factor errors. I assumed it is common that one needs to
>> translate a CFT into DFT when coding a paper up, and the correct
>> compensation to the normalization factors will surface if one does the
>> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the
>> variable
>> is angular frequency, but it's been a while since I did that last time.
>>
>> - Yu
>>
>> NumPy-Discussion mailing list
>
>> NumPy-Discussion@
>
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
>
>
>
> --
> Sent from: http://numpy-discussion.10968.n7.nabble.com/
> _______________________________________________
> NumPy-Discussion mailing list

> NumPy-Discussion@

> https://mail.python.org/mailman/listinfo/numpy-discussion

Hello all,
the discussion on this topic has been stagnant for the past couple of weeks,
so I just wanted to ask if anyone has any alternative names for the new
normalization option that would like to share.

If not, I'd suggest that we move on with "norm=forward", which seems to be a
more straightforward choice than the "norm=inverse" naming alternative. I
can wait a couple of days for possible new recommendations to be submitted,
and will then recommit to the open PR to account for the new kwarg name.

In terms of the name for the "norm=ortho" option, I suggest that we keep it
as is for now so that we don't introduce two API changes at once. If
desired, we can discuss it separately and open a new PR introducing a name
such as "norm=unitary" or "unit" as recommended in previous messages. I'm
happy to handle that if you think it'd be a useful change.

Chris





--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Gregory Lee

norm='forward' is my preference out of the names suggested so far. The option seems reasonable and should be pretty low maintenance to add.

For SciPy, we would probably be willing to make the corresponding changes in the scipy.fft module (but probably not in the outdated scipy.fftpack module).


On Wed, Jun 24, 2020 at 1:38 PM Ross Barnowski <[hidden email]> wrote:
I think it's also important to get the thoughts of the SciPy community on this topic so that we avoid divergence between numpy.fft and scipy.fft. I would recommend sending this discussion to the scipy mailing list as well.

~Ross

On Tue, Jun 23, 2020 at 4:11 PM Feng Yu <[hidden email]> wrote:
Your approach sounds good to me.

Thanks,

Yu

On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris <[hidden email]> wrote:
Chris Vavaliaris wrote
> Hello,
>
> - my first reaction would be that the less argument names we change at a
> time the better, so that we don't confuse people or cause codes written
> with
> previous NumPy versions to break. Personally I always think of "ortho" as
> "orthonormal", which immediately brings "unit norm" to mind, but I have no
> problem whatsoever with changing its name to "unitary" or maybe "unit",
> which I'd probably choose if we were writing the routines from scratch.
>
> - In terms of the "inverse" name option, I do believe that it'd be a
> confusing choice since "inverse" is used to describe the inverse FFT; if
> we
> choose to stick with a name that's based on the fact that this scaling is
> opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a
> better choice. However, following Ross' comment, I think we could choose a
> name based on the fact that the forward transform is now scaled by `n`,
> instead of the backward one as in the default "norm=None". In this case,
> I'd
> suggest "norm=forward", which we can also nicely abbreviate to the
> 4-character form "norm=forw" if desirable.
>
> Chris
>
>
> Feng Yu wrote
>> Hi,
>>
>> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'.
>> Since we are in general working with complex numbers, I do suggest
>> unitary
>> over ortho.
>> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) and (
>> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT)
>>
>> 2. I share Chris's concern about 'inverse', but I could not come up with
>> a
>> nice name.
>>
>> 3. Now that we are at this, should we also describe the corresponding
>> continuum limit of FFT and iFFT in the documentation?
>>
>> A paragraph doing so could potentially also help people diagnose some of
>> the normalization factor errors. I assumed it is common that one needs to
>> translate a CFT into DFT when coding a paper up, and the correct
>> compensation to the normalization factors will surface if one does the
>> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the
>> variable
>> is angular frequency, but it's been a while since I did that last time.
>>
>> - Yu
>>
>> NumPy-Discussion mailing list
>
>> NumPy-Discussion@
>
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
>
>
>
> --
> Sent from: http://numpy-discussion.10968.n7.nabble.com/
> _______________________________________________
> NumPy-Discussion mailing list

> NumPy-Discussion@

> https://mail.python.org/mailman/listinfo/numpy-discussion

Hello all,
the discussion on this topic has been stagnant for the past couple of weeks,
so I just wanted to ask if anyone has any alternative names for the new
normalization option that would like to share.

If not, I'd suggest that we move on with "norm=forward", which seems to be a
more straightforward choice than the "norm=inverse" naming alternative. I
can wait a couple of days for possible new recommendations to be submitted,
and will then recommit to the open PR to account for the new kwarg name.

In terms of the name for the "norm=ortho" option, I suggest that we keep it
as is for now so that we don't introduce two API changes at once. If
desired, we can discuss it separately and open a new PR introducing a name
such as "norm=unitary" or "unit" as recommended in previous messages. I'm
happy to handle that if you think it'd be a useful change.

Chris





--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

leofang
Hi all,


Since I brought this issue from CuPy to Numpy, I'd like to see a decision
made sooner than later so that downstream libraries like SciPy and CuPy can
act accordingly. I think norm='forward' is fine. If there're still people
unhappy with it after my reply, I'd suggest norm='reverse'. It has the same
meaning, but is less confusing (than 'inverse' or other choices on the
table) to me.


Best,
Leo



--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Sebastian Berg
On Fri, 2020-06-26 at 21:53 -0700, leofang wrote:

> Hi all,
>
>
> Since I brought this issue from CuPy to Numpy, I'd like to see a
> decision
> made sooner than later so that downstream libraries like SciPy and
> CuPy can
> act accordingly. I think norm='forward' is fine. If there're still
> people
> unhappy with it after my reply, I'd suggest norm='reverse'. It has
> the same
> meaning, but is less confusing (than 'inverse' or other choices on
> the
> table) to me.
>
I expect "forward" is good (if I misread something please correct me),
and I think we can go ahead with it, sorry for the delay.  However, I
have send an email to scipy-dev, since we should give them at least a
heads-up, and if you do not mind, I would wait a few days to actually
merge (although we can also simply reverse, as long as CuPy does not
have a release with it).

It might be nice to expand the kwarg docs slightly with a sentence for
each normalization mode?  Refering to `np.fft` docs is good, but if we
can squeeze in a short refresher and refer there for details/formula it
would be nicer.
I feel "forward" is very intuitive, but only after pointing out that it
is related to whether the fft or ifft has the normalization factor.

Cheers,

Sebastian


>
> Best,
> Leo
>
>
>
> --
> Sent from: http://numpy-discussion.10968.n7.nabble.com/
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Neal Becker
Honestly, I don't find "forward" very informative.  There isn't any real convention on whether FFT of IFFT have any normalization.  
To the best of my experience, either forward or inverse could be normalized by 1/N, or each normalized by 1/sqrt(N), or neither
could be normalized.  I will say my expertise is in signal processing and communications.

Perhaps
norm = {full, half, none} would be clearest to me.

Thanks,
Neal

On Sat, Jun 27, 2020 at 10:40 AM Sebastian Berg <[hidden email]> wrote:
On Fri, 2020-06-26 at 21:53 -0700, leofang wrote:
> Hi all,
>
>
> Since I brought this issue from CuPy to Numpy, I'd like to see a
> decision
> made sooner than later so that downstream libraries like SciPy and
> CuPy can
> act accordingly. I think norm='forward' is fine. If there're still
> people
> unhappy with it after my reply, I'd suggest norm='reverse'. It has
> the same
> meaning, but is less confusing (than 'inverse' or other choices on
> the
> table) to me.
>

I expect "forward" is good (if I misread something please correct me),
and I think we can go ahead with it, sorry for the delay.  However, I
have send an email to scipy-dev, since we should give them at least a
heads-up, and if you do not mind, I would wait a few days to actually
merge (although we can also simply reverse, as long as CuPy does not
have a release with it).

It might be nice to expand the kwarg docs slightly with a sentence for
each normalization mode?  Refering to `np.fft` docs is good, but if we
can squeeze in a short refresher and refer there for details/formula it
would be nicer.
I feel "forward" is very intuitive, but only after pointing out that it
is related to whether the fft or ifft has the normalization factor.

Cheers,

Sebastian


>
> Best,
> Leo
>
>
>
> --
> Sent from: http://numpy-discussion.10968.n7.nabble.com/
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion


--
Those who don't understand recursion are doomed to repeat it

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Andras Deak
On Sun, Jun 28, 2020 at 9:37 PM Neal Becker <[hidden email]> wrote:
>
> Honestly, I don't find "forward" very informative.  There isn't any real convention on whether FFT of IFFT have any normalization.
> To the best of my experience, either forward or inverse could be normalized by 1/N, or each normalized by 1/sqrt(N), or neither
> could be normalized.  I will say my expertise is in signal processing and communications.
>
> Perhaps
> norm = {full, half, none} would be clearest to me.

If I understand your point correctly and the discussion so far, the
intention here is to use the keyword to denote the convention for an
FFT-IFFT pair rather than just normalization in a single
transformation (either FFT or IFFT).
The idea being that calling ifft on the output of fft while using the
same `norm` would be more or less identity. This would work for
"half", but not for, say, "full". We need to come up with a name that
specifies where normalization happens with regards to the
forward-inverse pair.
Does this make sense, considering your point?

András

>
> Thanks,
> Neal
>
> On Sat, Jun 27, 2020 at 10:40 AM Sebastian Berg <[hidden email]> wrote:
>>
>> On Fri, 2020-06-26 at 21:53 -0700, leofang wrote:
>> > Hi all,
>> >
>> >
>> > Since I brought this issue from CuPy to Numpy, I'd like to see a
>> > decision
>> > made sooner than later so that downstream libraries like SciPy and
>> > CuPy can
>> > act accordingly. I think norm='forward' is fine. If there're still
>> > people
>> > unhappy with it after my reply, I'd suggest norm='reverse'. It has
>> > the same
>> > meaning, but is less confusing (than 'inverse' or other choices on
>> > the
>> > table) to me.
>> >
>>
>> I expect "forward" is good (if I misread something please correct me),
>> and I think we can go ahead with it, sorry for the delay.  However, I
>> have send an email to scipy-dev, since we should give them at least a
>> heads-up, and if you do not mind, I would wait a few days to actually
>> merge (although we can also simply reverse, as long as CuPy does not
>> have a release with it).
>>
>> It might be nice to expand the kwarg docs slightly with a sentence for
>> each normalization mode?  Refering to `np.fft` docs is good, but if we
>> can squeeze in a short refresher and refer there for details/formula it
>> would be nicer.
>> I feel "forward" is very intuitive, but only after pointing out that it
>> is related to whether the fft or ifft has the normalization factor.
>>
>> Cheers,
>>
>> Sebastian
>>
>>
>> >
>> > Best,
>> > Leo
>> >
>> >
>> >
>> > --
>> > Sent from: http://numpy-discussion.10968.n7.nabble.com/
>> > _______________________________________________
>> > NumPy-Discussion mailing list
>> > [hidden email]
>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>> >
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> [hidden email]
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
>
> --
> Those who don't understand recursion are doomed to repeat it
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Numpy FFT normalization options issue (addition of new option)

Peter Bell
>> Honestly, I don't find "forward" very informative.  There isn't any real convention on whether FFT of IFFT have any normalization.
>> To the best of my experience, either forward or inverse could be normalized by 1/N, or each normalized by 1/sqrt(N), or neither
>> could be normalized.  I will say my expertise is in signal processing and communications.
>>
>> Perhaps
>> norm = {full, half, none} would be clearest to me.

>If I understand your point correctly and the discussion so far, the
>intention here is to use the keyword to denote the convention for an
>FFT-IFFT pair rather than just normalization in a single
>transformation (either FFT or IFFT).
>The idea being that calling ifft on the output of fft while using the
>same `norm` would be more or less identity. This would work for
>"half", but not for, say, "full". We need to come up with a name that
>specifies where normalization happens with regards to the
>forward-inverse pair.

For what it's worth, I'm not sure that norm referring to a pair of transforms was ever a conscious decision. The numpy issue that first proposed the norm argument was gh-2142 which references scipy.fftpack's discrete cosine transforms. However, fftpack's dct never applied a 1/N normalization factor in either direction. So, norm=None really did mean "no normalization". It was then carried over to NumPy with None instead meaning "default normalization".

Unfortunately, this means norm=None could easily be mistaken for "no normalization", and would make accepting norm="none" terribly confusing. To break this confusion, I think the documentation should refer to norm={"backward", "ortho", "forward"} where "backward" is a synonym for norm=None.

As an aside, the history with the dct makes it clear the choice was "ortho" and not "unitary" because the dct is a real transform.

-Peter


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion