Numpy: numpy.fft.fft에서 매우 긴 런타임 (Trac # 1266)

_ @ endolith이 (가) 2009-11-20_에 작성했습니다.

관련 : # 1177 http://projects.scipy.org/scipy/ticket/949

_ @ rgommers 님 이 2011-03-01_에 작성했습니다.

_ @ rgommers 님 이 2011-03-01_에 작성했습니다.

David C.는 필요한 경우 Bluestein 변환을 구현했습니다. https://github.com/cournape/numpy/tree/bluestein

곧 Numpy 트렁크에 착륙 할 것입니다.

2011-03-25에 @mwiebe가 마일스톤을 Unscheduled 로 변경 했습니다.

이 홍보에서는 작은 소수에 대한 패딩이 제안됩니다.
https://github.com/scipy/scipy/pull/3144
더 나은 패딩 크기를 얻는 기능을 갖는 것은 numpys fftpack에서 유용한 유틸리티가 될 수 있습니다.

예, m = 2 ** nextpow2(2 * n - 1) 대신 next_regular 함수와 같은 것을 사용하는 것이 더 빠릅니다.

또한 점점 더 짧은 배열에서 statsmodels 자기 상관 함수 를 통해 pymbar 의

 np.fft.fftpack._fft_cache.clear()

메모리 요구 사항이 위험하게 증가하지 않도록합니다. 이것은 이상적인 해결책이 아닌 것 같습니다. "memsafe = True"와 같은 kwarg 및 / 또는 전역 변수를 명시 적으로 참조하지 않고 수동으로 캐시를 지우는 기능을 사용하는 것이 좋습니다.

@juliantaylor Padding은 일반 FFT에 적용 할 수 없습니다.

@rgommers Bluestein 알고리즘은 https://github.com/scipy/scipy/issues/4288 에서처럼 프라임 크기에 대한 FFT 속도를 높이지만 복잡한 처프의 사전 계산이 필요하며 메모리에 짹짹 거리고 반복적으로 데이터 청크에 재사용합니다. 그래서 이것이 numpy에 좋은지 확실하지 않고이 응용 프로그램에 대해 scipy.fftpack.czt를 연기 할 수 있습니까?

어쨌든 나는 이것이 https://github.com/numpy/numpy/issues/1177 의 복제본으로 닫힐 수 있다고 생각합니까? Rader의 알고리즘과 같은 것이 Bluestein의 알고리즘보다 낫지 않으면?

@smcantab 의 문제가 다른가요?

@endolith 이것은 오래 전이었습니다 :) 그러나 예, 이제 다시 보았으므로 다른 문제로 보입니다. 내가보고 한 문제는 여전히 관련이있을 수 있으며 작동하려면 pymbar에서 제안한 해결 방법을 구현해야했습니다.

참고로, 오디오 컨퍼런스에서이 예를 보여준 누군가를 만났습니다. 재현하기 쉽고 극단적입니다.

%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])

길이 1e6의 fft : 16 MILLIseconds

fft 길이 1e6 + 3 : 1 분 42 초

버그가 아닌 기능. FFTPACK은 크기가 숫자 2, 3, 4, 5의 곱으로 고려 될 때 "빠름"일뿐입니다. 큰 프라임 크기에 대해 더 빠른 알고리즘을 사용하려는 오랜 욕망이 있었지만 아직 구현되지 않았습니다. 100003은 소수입니다.

나는 그것을 "기능"이라고 부르지 않을 것이지만 그것은 정상이며 버그가 아닙니다. :)

https://github.com/scipy/scipy/issues/4288 에는 Bluestein의 알고리즘이 있지만 복잡한 처프의 사전 계산이 필요하므로 어떤 소수 크기에서 가치가 있는지 확인하기 위해 몇 가지 테스트를 수행해야합니다.

흥미 롭군. 내가 아는 가장 중요한 것은 Julia와 Matlab의 기본 fft 구현에는 이러한 동작이 없다는 것입니다. 이 동작을 피하기 위해 Julia 구현이 무엇을하는지 궁금합니다.

Julia와 Matlab은 FFTW를 호출하는데 라이센스 때문에 할 수 없습니다.

FFTW에 대한 Python 바인딩이 있습니다. pyFFTW는 다소 최신 인 것 같습니다. FFT 속도가 문제라면 아마도 그 방법 일 것입니다. FFTPACK은 그 당시에는 좋은 구현 이었지만 코드와 하드웨어는 계속 발전했습니다.

@charris 나는 정보에 확실히 감사하고 그것은 불행하지만 라이센스와 관련하여 의미가 있습니다.

@standarddeviant FFTW를 사용하도록 numpy / scipy 위에 pyfftw를 원숭이 패치 할 수도 있습니다.

이것은 numpy 1.17에서 수정되어야합니다.

감사합니다 @mreineck , 닫기