Re: [Numpy-discussion] fftfreq very slow; rfftfreq incorrect?

[Stefan v. d. W. <st...@su...>]

On Wed, Aug 30, 2006 at 12:04:22PM +0100, Andrew Jaffe wrote:
> the current implementation of fftfreq (which is meant to return the=20
> appropriate frequencies for an FFT) does the following:
>=20
>      k =3D range(0,(n-1)/2+1)+range(-(n/2),0)
>      return array(k,'d')/(n*d)
>=20
> I have tried this with very long (2**24) arrays, and it is ridiculously=
=20
> slow. Should this instead use arange (or linspace?) and concatenate=20
> rather than converting the above list? This seems to result in=20
> acceptable performance, but we could also perhaps even pre-allocate the=
=20
> space.

Please try the attached benchmark.

> The numpy.fft.rfftfreq seems just plain incorrect to me. It seems to=20
> produce lots of duplicated frequencies, contrary to the actual output o=
f=20
> rfft:
>=20
> def rfftfreq(n,d=3D1.0):
>      """ rfftfreq(n, d=3D1.0) -> f
>=20
>      DFT sample frequencies (for usage with rfft,irfft).
>=20
>      The returned float array contains the frequency bins in
>      cycles/unit (with zero at the start) given a window length n and a
>      sample spacing d:
>=20
>        f =3D [0,1,1,2,2,...,n/2-1,n/2-1,n/2]/(d*n)   if n is even
>        f =3D [0,1,1,2,2,...,n/2-1,n/2-1,n/2,n/2]/(d*n)   if n is odd
>=20
>        **** None of these should be doubled, right?
>=20
>      """
>      assert isinstance(n,int)
>      return array(range(1,n+1),dtype=3Dint)/2/float(n*d)

Please produce a code snippet to demonstrate the problem.  We can then
fix the bug and use your code as a unit test.

Regards
St=E9fan