From the docstring:
"A[0] contains the zero-frequency term (the mean of the signal)" And yet, consistent w/ the definition given in the docstring (and included w/ an earlier email), the code gives, e.g.:
import numpy as np x = np.ones((16,)); x array([ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]) y = np.fft.fft(x); y array([ 16.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j])
i.e., the zero-th term is the sum, not the mean (which, again, is consistent w/ the stated defining formula). So, same ol', same ol': bug in the doc (presumably) or bug in the code? DG
On 07/12/2010 11:43 AM, David Goldsmith wrote:
From the docstring:
"A[0] contains the zero-frequency term (the mean of the signal)"
And yet, consistent w/ the definition given in the docstring (and included w/ an earlier email), the code gives, e.g.:
import numpy as np x = np.ones((16,)); x array([ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]) y = np.fft.fft(x); y array([ 16.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j])
i.e., the zero-th term is the sum, not the mean (which, again, is consistent w/ the stated defining formula).
So, same ol', same ol': bug in the doc (presumably) or bug in the code?
Bug in the doc. Good catch. "mean" is correct for the ifft, not for the fft. Eric
DG
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Jul 12, 2010 at 3:04 PM, Eric Firing <efiring@hawaii.edu> wrote:
On 07/12/2010 11:43 AM, David Goldsmith wrote:
From the docstring:
"A[0] contains the zero-frequency term (the mean of the signal)"
And yet, consistent w/ the definition given in the docstring (and included w/ an earlier email), the code gives, e.g.:
import numpy as np x = np.ones((16,)); x array([ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]) y = np.fft.fft(x); y array([ 16.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j])
i.e., the zero-th term is the sum, not the mean (which, again, is consistent w/ the stated defining formula).
So, same ol', same ol': bug in the doc (presumably) or bug in the code?
Bug in the doc. Good catch.
Thanks. (In case you hadn't noticed, I'm detail-oriented to a fault.) :-/ DG
"mean" is correct for the ifft, not for the fft.
Eric
DG
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves)
On 13/07/10 08:04, Eric Firing wrote:
On 07/12/2010 11:43 AM, David Goldsmith wrote:
From the docstring:
"A[0] contains the zero-frequency term (the mean of the signal)"
And yet, consistent w/ the definition given in the docstring (and included w/ an earlier email), the code gives, e.g.:
import numpy as np x = np.ones((16,)); x array([ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]) y = np.fft.fft(x); y array([ 16.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j])
i.e., the zero-th term is the sum, not the mean (which, again, is consistent w/ the stated defining formula).
So, same ol', same ol': bug in the doc (presumably) or bug in the code?
Bug in the doc. Good catch. "mean" is correct for the ifft, not for the fft.
Eric
I'd say that a pointer to a discussion about normalization of ffts would be good here. The issue is that numpy is doing a normalization to len(x) for the inverse fft. However to make ffts unitary it should actually be that fft and ifft are normalized by sqrt(len(x)). And some fft implementations don't do normalizations at all (FFTW). Cheers Jochen
DG
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 13/07/10 08:04, Eric Firing wrote:
On 07/12/2010 11:43 AM, David Goldsmith wrote:
From the docstring:
"A[0] contains the zero-frequency term (the mean of the signal)"
And yet, consistent w/ the definition given in the docstring (and included w/ an earlier email), the code gives, e.g.:
import numpy as np x = np.ones((16,)); x array([ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]) y = np.fft.fft(x); y array([ 16.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j])
i.e., the zero-th term is the sum, not the mean (which, again, is consistent w/ the stated defining formula).
So, same ol', same ol': bug in the doc (presumably) or bug in the code?
Bug in the doc. Good catch. "mean" is correct for the ifft, not for the fft.
Eric
I'd say that a pointer to a discussion about normalization of ffts would be good here. The issue is that numpy is doing a normalization to len(x) for the inverse fft. However to make ffts unitary it should actually be that fft and ifft are normalized by sqrt(len(x)). And some fft implementations don't do normalizations at all (FFTW).
Interesting comment: it made me run down the fftpack tutorial<http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/>josef has alluded to in the past to see if the suggested pointer could point
2010/7/12 Jochen Schröder <cycomanic@gmail.com> there without having to write a lot of new content. What I found was that although the scipy basic fft functions don't support it (presumably because they're basically just wrappers for the numpy fft functions), scipy's discrete cosine transforms support an "norm=ortho" keyword argument/value pair that enables the function to return the unitary versions that you describe above. There isn't much narrative explanation of the issue yet, but it got me wondering: why don't the fft functions support this? If there isn't a "good" reason, I'll go ahead and submit an enhancement ticket. DG
Cheers Jochen
DG
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves)
On Mon, Jul 12, 2010 at 8:26 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
2010/7/12 Jochen Schröder <cycomanic@gmail.com>
On 13/07/10 08:04, Eric Firing wrote:
On 07/12/2010 11:43 AM, David Goldsmith wrote:
From the docstring:
"A[0] contains the zero-frequency term (the mean of the signal)"
And yet, consistent w/ the definition given in the docstring (and included w/ an earlier email), the code gives, e.g.:
> import numpy as np > x = np.ones((16,)); x array([ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]) > y = np.fft.fft(x); y array([ 16.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j])
i.e., the zero-th term is the sum, not the mean (which, again, is consistent w/ the stated defining formula).
So, same ol', same ol': bug in the doc (presumably) or bug in the code?
Bug in the doc. Good catch. "mean" is correct for the ifft, not for the fft.
Eric
I'd say that a pointer to a discussion about normalization of ffts would be good here. The issue is that numpy is doing a normalization to len(x) for the inverse fft. However to make ffts unitary it should actually be that fft and ifft are normalized by sqrt(len(x)). And some fft implementations don't do normalizations at all (FFTW).
Interesting comment: it made me run down the fftpack tutorial<http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/>josef has alluded to in the past to see if the suggested pointer could point there without having to write a lot of new content. What I found was that although the scipy basic fft functions don't support it (presumably because they're basically just wrappers for the numpy fft functions), scipy's discrete cosine transforms support an "norm=ortho" keyword argument/value pair that enables the function to return the unitary versions that you describe above. There isn't much narrative explanation of the issue yet, but it got me wondering: why don't the fft functions support this? If there isn't a "good" reason, I'll go ahead and submit an enhancement ticket.
Having seen no post of a "good reason," I'm going to go ahead and file enhancement tickets. DG
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Goldsmith skrev:
Interesting comment: it made me run down the fftpack tutorial <http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/> josef has alluded to in the past to see if the suggested pointer could point there without having to write a lot of new content. What I found was that although the scipy basic fft functions don't support it (presumably because they're basically just wrappers for the numpy fft functions), scipy's discrete cosine transforms support an "norm=ortho" keyword argument/value pair that enables the function to return the unitary versions that you describe above. There isn't much narrative explanation of the issue yet, but it got me wondering: why don't the fft functions support this? If there isn't a "good" reason, I'll go ahead and submit an enhancement ticket.
Having seen no post of a "good reason," I'm going to go ahead and file enhancement tickets.
Hi, I have worked on fourier transforms and I think normalization is generally seen as a whole : fft + ifft should be the identity function, thus the necessity of a normalization, which often done on the ifft. As one of the previous poster mentioned, sqrt(len(x)) is often seen as a good compromise to split the normalization equally between fft and ifft. In the sound community though, the whole normalization often done after the fft, such that looking at the amplitude spectrum gives the correct amplitude values for the different components of the sound (sinusoids). My guess is that normalization requirements are different for every user: that's why I like the no normalization approach of fftw, such that anyone does whatever he/she/it wants. Best regards, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMPuD6AAoJEBdvyODiyJI4pEEIAJRcNAMzjS47MhAMc8nK+Ds/ hkFuI7IPsREPLZ7N5roOny7eCq2+DK2r9Qx4+43ZMU/rPouYHmugpTSQcL7cIgmW AZT7ll//BgK4PgN4x7mXj5p1BK+XsNTabNoaTswPsOYy84CvTawQ6eRi+FGQZK+u OXMt8AsyVn60thP8BVRDUXLnmNXKz2qT9KYdStrby3WvDnvoIFSOcy6u2VRuEOQR 3fKzSU30p9bd8og4Rz2wXz2IeNv+apOP1VQGEY0zfN7r8VC9yaiY/TNG0alSTT7o EpuphiIKoh+63he97MJvXgFFAVxhsAHHo5M8ZY7C48pwO99oNDx1kKFu+YtRcQY= =h0tq -----END PGP SIGNATURE-----
On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud <martin.raspaud@smhi.se>wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Goldsmith skrev:
Interesting comment: it made me run down the fftpack tutorial <http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/> josef has alluded to in the past to see if the suggested pointer could point there without having to write a lot of new content. What I found was that although the scipy basic fft functions don't support it (presumably because they're basically just wrappers for the numpy fft functions), scipy's discrete cosine transforms support an "norm=ortho" keyword argument/value pair that enables the function to return the unitary versions that you describe above. There isn't much narrative explanation of the issue yet, but it got me wondering: why don't the fft functions support this? If there isn't a "good" reason, I'll go ahead and submit an enhancement
ticket.
Having seen no post of a "good reason," I'm going to go ahead and file enhancement tickets.
Hi,
I have worked on fourier transforms and I think normalization is generally seen as a whole : fft + ifft should be the identity function, thus the necessity of a normalization, which often done on the ifft.
As one of the previous poster mentioned, sqrt(len(x)) is often seen as a good compromise to split the normalization equally between fft and ifft.
In the sound community though, the whole normalization often done after the fft, such that looking at the amplitude spectrum gives the correct amplitude values for the different components of the sound (sinusoids).
My guess is that normalization requirements are different for every user: that's why I like the no normalization approach of fftw, such that anyone does whatever he/she/it wants.
I get the picture: in the docstring, refer people to fftw. DG
On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud <martin.raspaud@smhi.se>wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Goldsmith skrev:
Interesting comment: it made me run down the fftpack tutorial <http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/> josef has alluded to in the past to see if the suggested pointer could point there without having to write a lot of new content. What I found was that although the scipy basic fft functions don't support it (presumably because they're basically just wrappers for the numpy fft functions), scipy's discrete cosine transforms support an "norm=ortho" keyword argument/value pair that enables the function to return the unitary versions that you describe above. There isn't much narrative explanation of the issue yet, but it got me wondering: why don't the fft functions support this? If there isn't a "good" reason, I'll go ahead and submit an enhancement
ticket.
Having seen no post of a "good reason," I'm going to go ahead and file enhancement tickets.
Hi,
I have worked on fourier transforms and I think normalization is generally seen as a whole : fft + ifft should be the identity function, thus the necessity of a normalization, which often done on the ifft.
As one of the previous poster mentioned, sqrt(len(x)) is often seen as a good compromise to split the normalization equally between fft and ifft.
In the sound community though, the whole normalization often done after the fft, such that looking at the amplitude spectrum gives the correct amplitude values for the different components of the sound (sinusoids).
My guess is that normalization requirements are different for every user: that's why I like the no normalization approach of fftw, such that anyone does whatever he/she/it wants.
I get the picture: in the docstring, refer people to fftw.
DG
I can't find this fftw function in either numpy or scipy - where is it? DG
On Tue, Jul 20, 2010 at 6:02 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud <martin.raspaud@smhi.se>wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Goldsmith skrev:
Interesting comment: it made me run down the fftpack tutorial <http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/
josef has alluded to in the past to see if the suggested pointer could point there without having to write a lot of new content. What I found was that although the scipy basic fft functions don't support it (presumably because they're basically just wrappers for the numpy fft functions), scipy's discrete cosine transforms
support
an "norm=ortho" keyword argument/value pair that enables the function to return the unitary versions that you describe above. There isn't much narrative explanation of the issue yet, but it got me wondering: why don't the fft functions support this? If there isn't a "good" reason, I'll go ahead and submit an enhancement
ticket.
Having seen no post of a "good reason," I'm going to go ahead and file enhancement tickets.
Hi,
I have worked on fourier transforms and I think normalization is generally seen as a whole : fft + ifft should be the identity function, thus the necessity of a normalization, which often done on the ifft.
As one of the previous poster mentioned, sqrt(len(x)) is often seen as a good compromise to split the normalization equally between fft and ifft.
In the sound community though, the whole normalization often done after the fft, such that looking at the amplitude spectrum gives the correct amplitude values for the different components of the sound (sinusoids).
My guess is that normalization requirements are different for every user: that's why I like the no normalization approach of fftw, such that anyone does whatever he/she/it wants.
I get the picture: in the docstring, refer people to fftw.
DG
I can't find this fftw function in either numpy or scipy - where is it?
It is a GPL package so we don't use it. The fftw homepage is here<http://www.fftw.org/> . Chuck
On Wed, Jul 21, 2010 at 2:02 AM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud <martin.raspaud@smhi.se> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Goldsmith skrev:
Interesting comment: it made me run down the fftpack tutorial <http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/> josef has alluded to in the past to see if the suggested pointer could point there without having to write a lot of new content. What I found was that although the scipy basic fft functions don't support it (presumably because they're basically just wrappers for the numpy fft functions), scipy's discrete cosine transforms support an "norm=ortho" keyword argument/value pair that enables the function to return the unitary versions that you describe above. There isn't much narrative explanation of the issue yet, but it got me wondering: why don't the fft functions support this? If there isn't a "good" reason, I'll go ahead and submit an enhancement ticket.
Having seen no post of a "good reason," I'm going to go ahead and file enhancement tickets.
Hi,
I have worked on fourier transforms and I think normalization is generally seen as a whole : fft + ifft should be the identity function, thus the necessity of a normalization, which often done on the ifft.
As one of the previous poster mentioned, sqrt(len(x)) is often seen as a good compromise to split the normalization equally between fft and ifft.
In the sound community though, the whole normalization often done after the fft, such that looking at the amplitude spectrum gives the correct amplitude values for the different components of the sound (sinusoids).
My guess is that normalization requirements are different for every user: that's why I like the no normalization approach of fftw, such that anyone does whatever he/she/it wants.
I get the picture: in the docstring, refer people to fftw.
DG
I can't find this fftw function in either numpy or scipy - where is it?
It is a library for fft - the OP was referring to its conventions for normalization (i.e. no normalization) David
On Tue, Jul 20, 2010 at 5:47 PM, David Cournapeau <cournape@gmail.com>wrote:
On Wed, Jul 21, 2010 at 2:02 AM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith < d.l.goldsmith@gmail.com> wrote:
On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud <martin.raspaud@smhi.se
wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Goldsmith skrev:
Interesting comment: it made me run down the fftpack tutorial <
http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/>
josef has alluded to in the past to see if the suggested pointer could point there without having to write a lot of new content. What I found was that although the scipy basic fft functions
don't
support it (presumably because they're basically just wrappers
for
the numpy fft functions), scipy's discrete cosine transforms support an "norm=ortho" keyword argument/value pair that enables the function to return the unitary versions that you describe above. There isn't much narrative explanation of the issue yet, but it
got
me wondering: why don't the fft functions support this? If there isn't a "good" reason, I'll go ahead and submit an enhancement ticket.
Having seen no post of a "good reason," I'm going to go ahead and
file
enhancement tickets.
Hi,
I have worked on fourier transforms and I think normalization is generally seen as a whole : fft + ifft should be the identity function, thus the necessity of a normalization, which often done on the ifft.
As one of the previous poster mentioned, sqrt(len(x)) is often seen as a good compromise to split the normalization equally between fft and ifft.
In the sound community though, the whole normalization often done after the fft, such that looking at the amplitude spectrum gives the correct amplitude values for the different components of the sound (sinusoids).
My guess is that normalization requirements are different for every user: that's why I like the no normalization approach of fftw, such that anyone does whatever he/she/it wants.
I get the picture: in the docstring, refer people to fftw.
DG
I can't find this fftw function in either numpy or scipy - where is it?
It is a library for fft - the OP was referring to its conventions for normalization (i.e. no normalization)
That would have been helpful to have stated at the outset. So, what does all this amount to vis-a-vis the ticket I created suggesting that fft/ifft be enhanced w/ a norm keyword parameter? "Won't fix"? And what/why should anything be said about normalization if our functions only return one kind of normalization and that normalization is already well-documented (it is explicit in the provided definitions we use for the two transforms)? DG
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves)
On Tue, Jul 20, 2010 at 7:28 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
On Tue, Jul 20, 2010 at 5:47 PM, David Cournapeau <cournape@gmail.com>wrote:
On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith < d.l.goldsmith@gmail.com> wrote:
On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud <
martin.raspaud@smhi.se>
wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Goldsmith skrev:
Interesting comment: it made me run down the fftpack tutorial <
http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/>
josef has alluded to in the past to see if the suggested pointer could point there without having to write a lot of new content. What I found was that although the scipy basic fft functions
don't
support it (presumably because they're basically just wrappers
for
the numpy fft functions), scipy's discrete cosine transforms support an "norm=ortho" keyword argument/value pair that enables the function to return the unitary versions that you describe above. There isn't much narrative explanation of the issue yet, but it
got
me wondering: why don't the fft functions support this? If
On Wed, Jul 21, 2010 at 2:02 AM, David Goldsmith <d.l.goldsmith@gmail.com> wrote: there
isn't a "good" reason, I'll go ahead and submit an enhancement ticket.
Having seen no post of a "good reason," I'm going to go ahead and
file
enhancement tickets.
Hi,
I have worked on fourier transforms and I think normalization is generally seen as a whole : fft + ifft should be the identity function, thus the necessity of a normalization, which often done on the ifft.
As one of the previous poster mentioned, sqrt(len(x)) is often seen as a good compromise to split the normalization equally between fft and ifft.
In the sound community though, the whole normalization often done after the fft, such that looking at the amplitude spectrum gives the correct amplitude values for the different components of the sound (sinusoids).
My guess is that normalization requirements are different for every user: that's why I like the no normalization approach of fftw, such that anyone does whatever he/she/it wants.
I get the picture: in the docstring, refer people to fftw.
DG
I can't find this fftw function in either numpy or scipy - where is it?
It is a library for fft - the OP was referring to its conventions for normalization (i.e. no normalization)
That would have been helpful to have stated at the outset.
So, what does all this amount to vis-a-vis the ticket I created suggesting that fft/ifft be enhanced w/ a norm keyword parameter? "Won't fix"? And what/why should anything be said about normalization if our functions only return one kind of normalization and that normalization is already well-documented (it is explicit in the provided definitions we use for the two transforms)?
I for one would welcome no normalization, or at least user normalization since undoing the damage of the current normalization is work. How about a scale keyword? scale=None -- current behaviour, default. scale=some_number -- multiply the result by some_number. Can simplify when equal to 1. Chuck
participants (6)
-
Charles R Harris -
David Cournapeau -
David Goldsmith -
Eric Firing -
Jochen Schröder -
Martin Raspaud