[Numpy-discussion] numpy.fft, yet again

[David Cournapeau]

On Wed, Jul 21, 2010 at 2:02 AM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith <d.l.goldsmith at gmail.com>
> wrote:
>>
>> On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud <martin.raspaud at 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