[Numpy-discussion] numpy.fft, yet again

[David Goldsmith]

On Mon, Jul 12, 2010 at 8:26 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> 2010/7/12 Jochen Schröder <cycomanic at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100714/d7f8498c/attachment.html>