Just a heads-up. As I think the discussion seemed to settled on
"backwards" (default, identical to None), "forward" and the existing
"ortho".
Thus "forward" and "backward" are now new valid values for the `norm`
keyword argument to the fft functions in NumPy. (see
https://github.com/numpy/numpy/
>> 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
On Sun, Jun 28, 2020 at 9:37 PM Neal Becker 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 b
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 expe
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
> peop
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 ha
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).
O
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 wrote:
> Your approach sou
Your approach sounds good to me.
Thanks,
Yu
On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris
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
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 immediate
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
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#Th
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 t
On Thu, Jun 4, 2020 at 7:05 AM cvav 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 mai
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 som
15 matches
Mail list logo
