Numpy: Tiempos de ejecución extremadamente largos en numpy.fft.fft (Trac # 1266)

_ @ endolith escribió el 2009-11-20_

Relacionado: # 1177 http://projects.scipy.org/scipy/ticket/949

_ @ rgommers escribió el 2011-03-01_

_ @ rgommers escribió el 2011-03-01_

David C.ha implementado la transformación de Bluestein si la necesita: https://github.com/cournape/numpy/tree/bluestein

Esperemos que aterrice pronto en el maletero de Numpy.

Hito cambiado a Unscheduled por @mwiebe el 2011-03-25

en este pr se propone un acolchado a pequeños primos
https://github.com/scipy/scipy/pull/3144
tener la función para obtener un mejor tamaño de relleno podría ser una utilidad útil en numpys fftpack

Sí, en lugar de m = 2 ** nextpow2(2 * n - 1) será más rápido usar algo como la función next_regular

También me he encontrado con este problema usando la función detect_equilibration de pymbar que llama repetidamente a np.fft y np.ifft a través de la función de autocorrelación statsmodels en muchas matrices cada vez más cortas. Descubrí perfilar el código, lo que finalmente me llevó a este hilo. La única solución hasta ahora es llamar explícitamente

 np.fft.fftpack._fft_cache.clear()

para asegurarse de que el requisito de memoria no crezca peligrosamente. Sin embargo, esta no parece ser la solución ideal. Sería bueno tener un kwarg como "memsafe = True" y / o una función para borrar manualmente el caché sin hacer referencia explícita a la variable global.

@juliantaylor Padding no se aplica a FFT simples, ¿correcto? ¿Solo por convolución / correlación?

@rgommers El algoritmo de Bluestein acelera la FFT para tamaños principales, como se hace en https://github.com/scipy/scipy/issues/4288 , pero requiere el cálculo previo de chirridos complejos y es más eficiente cuando se mantiene el chirrido en la memoria y reutilizarlo repetidamente en fragmentos de datos. Entonces, no estoy seguro de si esto es bueno para numpy y tal vez solo difiera a scipy.fftpack.czt para esta aplicación.

De todos modos, creo que esto se puede cerrar como un duplicado de https://github.com/numpy/numpy/issues/1177 ? ¿A menos que algo más como el algoritmo de Rader sea mejor que el de Bluestein?

y el problema de @smcantab es diferente?

@endolith, esto fue hace mucho tiempo :) pero sí, ahora que lo miro de nuevo, parece un problema diferente. Sin embargo, el problema que informé podría ser relevante y tuve que implementar la solución que sugerí en pymbar para que funcione.

Para su información, me encontré con alguien en una conferencia de audio que me mostró este ejemplo. Es fácil de reproducir y extremo.

%time np.fft.fft( np.random.randn(100000) )
Wall time: 16 ms
Out[16]: 
array([ 196.58599022  +0.j        ,  -88.38483360 +89.2507627j ,
       -166.72250316+339.27161306j, ...,   12.22959535 -64.01621313j,
       -166.72250316-339.27161306j,  -88.38483360 -89.2507627j ])

%time np.fft.fft( np.random.randn(100003) )
Wall time: 1min 42s
Out[17]: 
array([  13.36160617  +0.j        , -314.86472577-340.44686425j,
       -258.36716707-170.43805382j, ...,  -21.18014704+441.3618185j ,
       -258.36716707+170.43805382j, -314.86472577+340.44686425j])

fft de longitud 1e6: 16 MILLIsegundos

fft de longitud 1e6 + 3: 1 MINUTO y 42 SEGUNDOS

Característica, no un error. FFTPACK solo es "rápido" cuando el tamaño se factoriza como un producto de los números 2, 3, 4, 5. Ha habido un deseo de larga data de usar un algoritmo más rápido para tamaños primos grandes, pero no se ha implementado. Tenga en cuenta que 100003 es primo.

No lo llamaría una "función", pero es normal y no un error. :)

https://github.com/scipy/scipy/issues/4288 tiene el algoritmo de Bluestein, pero requiere el cálculo previo de un chirp complejo, por lo que sería necesario hacer algunas pruebas para ver en qué tamaños principales vale la pena.

Interesante. Lo principal que sé es que la implementación fft predeterminada para Julia y Matlab no tiene este comportamiento. Tengo curiosidad por saber qué hace la implementación de Julia para evitar este comportamiento.

Julia y Matlab llaman a FFTW, lo que no podemos hacer debido a su licencia.

Tenga en cuenta que existen enlaces de Python para FFTW; pyFFTW parece bastante actual. Si la velocidad de FFT es una preocupación, probablemente ese sea el camino a seguir. FFTPACK fue una buena implementación para su época, pero el código y el hardware han avanzado.

@charris Definitivamente aprecio la información y eso es desafortunado, pero tiene sentido con respecto a la licencia.

@standarddeviant También puede aplicar un parche a pyfftw sobre numpy / scipy para que use FFTW

Esto debería arreglarse en numpy 1.17.

gracias @mreineck , cierre