[Numpy-discussion] numpy.fft, yet again
Wed Jul 14 21:22:43 CDT 2010
On Mon, Jul 12, 2010 at 8:26 PM, David Goldsmith <firstname.lastname@example.org>wrote:
> 2010/7/12 Jochen Schröder <email@example.com>
>> On 13/07/10 08:04, Eric Firing wrote:
>> > On 07/12/2010 11:43 AM, David Goldsmith wrote:
>> >> > From the docstring:
>> >> "A 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion