Numpy: Runtime yang sangat panjang di numpy.fft.fft (Trac # 1266)

_ @ endolith menulis pada 2009-11-20_

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

_ @ rgommers menulis pada 2011-03-01_

_ @ rgommers menulis pada 2011-03-01_

David C. telah menerapkan transformasi Bluestein jika Anda membutuhkannya: https://github.com/cournape/numpy/tree/bluestein

Semoga segera mendarat di bagasi Numpy.

Milestone diubah menjadi Unscheduled oleh @mwiebe pada tanggal 2011-03-25

dalam pr ini, padding ke bilangan prima kecil diusulkan
https://github.com/scipy/scipy/pull/3144
memiliki fungsi untuk mendapatkan ukuran padding yang lebih baik mungkin merupakan utilitas yang berguna di numpys fftpack

Ya, daripada m = 2 ** nextpow2(2 * n - 1) itu akan lebih cepat untuk menggunakan sesuatu seperti fungsi next_regular

Saya juga menemukan masalah ini menggunakan fungsi detect_equilibration dari pymbar yang berulang kali memanggil np.fft dan np.ifft melalui fungsi autokorelasi statsmodels pada banyak larik yang semakin pendek. Saya menemukan kode profil, yang pada akhirnya membawa saya ke utas ini. Satu-satunya solusi sejauh ini adalah menelepon secara eksplisit

 np.fft.fftpack._fft_cache.clear()

untuk memastikan bahwa kebutuhan memori tidak berkembang secara berbahaya. Ini tampaknya bukan solusi yang ideal. Alangkah baiknya jika memiliki kwarg seperti "memsafe = True" dan / atau fungsi untuk membersihkan cache secara manual tanpa mengacu pada variabel global secara eksplisit.

@juliantaylor Padding tidak berlaku untuk FFT biasa, benar? Hanya untuk konvolusi / korelasi?

@rgommers Algoritme Bluestein memang mempercepat FFT untuk ukuran prima, seperti yang dilakukan di https://github.com/scipy/scipy/issues/4288 , tetapi memerlukan praperhitungan bunyi kica yang kompleks, dan paling efisien saat Anda menyimpan berkicau dalam memori dan berulang kali menggunakannya kembali pada potongan data. Jadi saya tidak yakin apakah ini bagus untuk numpy dan mungkin hanya tunduk pada scipy.fftpack.czt untuk aplikasi ini?

Pokoknya menurut saya ini bisa ditutup sebagai duplikat dari https://github.com/numpy/numpy/issues/1177 ? Kecuali sesuatu yang lain seperti algoritme Rader lebih baik dari Bluestein?

dan masalah @smcantab berbeda?

@endolith ini sudah lama sekali :) tapi ya, sekarang saya melihatnya lagi sepertinya ada masalah yang berbeda. Masalah yang saya laporkan mungkin masih relevan dan saya harus menerapkan solusi yang saya sarankan di pymbar agar berfungsi.

FYI, saya bertemu seseorang di konferensi audio yang menunjukkan contoh ini. Mudah untuk direproduksi dan ekstrim.

%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 dengan panjang 1e6: 16 MILLIseconds

fft dengan panjang 1e6 + 3: 1 MENIT dan 42 DETIK

Fitur, bukan bug. FFTPACK hanya "cepat" jika faktor ukuran sebagai produk dari angka 2, 3, 4, 5. Sudah lama ada keinginan untuk menggunakan algoritme yang lebih cepat untuk ukuran utama yang besar, tetapi belum diterapkan. Perhatikan bahwa 100003 adalah bilangan prima.

Saya tidak akan menyebutnya sebagai "fitur", tetapi itu normal dan bukan bug. :)

https://github.com/scipy/scipy/issues/4288 memiliki algoritme Bluestein, tetapi memerlukan praperhitungan kicauan yang kompleks, jadi perlu melakukan beberapa pengujian untuk melihat ukuran prima mana yang membuatnya berharga.

Menarik. Hal utama yang saya tahu adalah bahwa implementasi fft default untuk Julia dan Matlab tidak memiliki perilaku ini. Saya ingin tahu apa yang dilakukan penerapan Julia untuk menghindari perilaku ini.

Julia dan Matlab memanggil FFTW, yang tidak dapat kami lakukan karena lisensinya.

Perhatikan bahwa ada binding Python untuk FFTW; pyFFTW sepertinya agak mutakhir. Jika kecepatan FFT menjadi perhatian, mungkin itulah cara terbaiknya. FFTPACK adalah implementasi yang baik pada masanya, tetapi kode dan perangkat keras telah berpindah.

@charris Saya sangat menghargai infonya dan itu sangat disayangkan, tetapi masuk akal mengenai lisensinya.

@standarddeviant Anda juga dapat menambal pyfftw di atas numpy / scipy untuk membuatnya menggunakan FFTW

Ini harus diperbaiki di numpy 1.17.

terima kasih @mreineck , tutup