Numpy: Numpy.fft.fft (Trac # 1266) में बहुत लंबे समय तक चलने वाली दौड़

को निर्मित 19 अक्तू॰ 2012 · 19टिप्पणियाँ · स्रोत: numpy/numpy

_Original टिकट http://projects.scipy.org/numpy/ticket/1266 2009-10-19 पर trac user koehler द्वारा, अज्ञात को सौंपा गया ।_

हालाँकि numpy.fft.fft का दस्तावेज़ीकरण बताता है कि:
"यह दो की ना पॉवर के लिए सबसे अधिक कुशल है। यह fft's के विभिन्न आकारों के लिए कार्यशील मेमोरी का एक कैश भी संग्रहीत करता है, इसलिए यदि आप इसे बहुत अधिक भिन्न n के साथ कई बार कॉल करते हैं, तो आप सैद्धांतिक रूप से मेमोरी समस्याओं में चल सकते हैं।" , मुझे लगता है कि fft रनटाइम में इस विषमता की रिपोर्ट करना महत्वपूर्ण हो सकता है।
सरणी की लंबाई पर निर्भर, fft रनटाइम वास्तव में चरम बदलता है:

[ipython shell, from numpy import *]
In [1]: %time fft.fft(zeros(119516))
CPU times: user 22.83 s, sys: 0.39 s, total: 23.23 s
Wall time: 23.53 s

In [3]: %time fft.fft(zeros(119517))
CPU times: user 36.33 s, sys: 0.08 s, total: 36.40 s
Wall time: 36.51 s

In [5]: %time fft.fft(zeros(119518))
CPU times: user 4.88 s, sys: 0.08 s, total: 4.96 s
Wall time: 5.02 s

In [7]: %time fft.fft(zeros(119519))
CPU times: user 0.45 s, sys: 0.00 s, total: 0.45 s
Wall time: 0.45 s

In [9]: %time fft.fft(zeros(119515))
CPU times: user 0.07 s, sys: 0.00 s, total: 0.08 s
Wall time: 0.08 s

In [11]: %time fft.fft(zeros(119514))
CPU times: user 15.84 s, sys: 0.06 s, total: 15.90 s
Wall time: 15.95 s

In [13]: %time fft.fft(zeros(119513))
CPU times: user 272.75 s, sys: 1.03 s, total: 273.78 s
Wall time: 275.63 s

00 - Bug numpy.fft

स्रोत

thouis

सबसे उपयोगी टिप्पणी

यह संख्या 1.17 में तय की जानी चाहिए।

mreineck 5 अप्रैल 2019

👍2

सभी 19 टिप्पणियाँ

_ @ एंडोलिथ ने 2009-11-20_ पर लिखा

संबंधित: # 1177 http://projects.scipy.org/scipy/ticket/949

numpy-gitbot 23 अक्तू॰ 2012

_ @ rgommers ने 2011-03-01_ पर लिखा

numpy-gitbot 23 अक्तू॰ 2012

_ @ rgommers ने 2011-03-01_ पर लिखा

डेविड सी ने जरूरत पड़ने पर ब्लूस्टीन ट्रांसफ़ॉर्म लागू किया है: https://github.com/cournape/numpy/tree/bluestein

उम्मीद है कि Numpy ट्रंक में जल्द ही जमीन चाहिए।

numpy-gitbot 23 अक्तू॰ 2012

2011-03-25 पर @mwiebe द्वारा मील का पत्थर Unscheduled में बदल गया

numpy-gitbot 23 अक्तू॰ 2012

इस जनसंपर्क में छोटे अपराधों के लिए एक पैडिंग प्रस्तावित है
https://github.com/scipy/scipy/pull/3144
एक बेहतर पैडिंग आकार प्राप्त करने के लिए कार्य करने के बाद अंक fftpack में एक उपयोगी उपयोगिता हो सकती है

juliantaylor 18 जन॰ 2014

हां, m = 2 ** nextpow2(2 * n - 1) बजाय next_regular फ़ंक्शन जैसी किसी चीज़ का उपयोग करना तेज़ होगा

endolith 19 जन॰ 2014

मैं भी इस मुद्दे पर pymbar के डेटामॉडेल्स ऑटोक्रॉलेशन फ़ंक्शन के माध्यम से कॉल

 np.fft.fftpack._fft_cache.clear()

यह सुनिश्चित करने के लिए कि स्मृति की आवश्यकता खतरनाक रूप से न बढ़े। हालांकि यह आदर्श समाधान नहीं लगता है। यह अच्छा होगा कि या तो कोई कंवर जैसे "मेमसेफ़ = ट्रू" और / या किसी फ़ंक्शन को मैन्युअल रूप से वैश्विक वैरिएबल का उल्लेख किए बिना कैशे को साफ़ करें।

smcantab 26 जन॰ 2015

@juliantaylor पैडिंग सादे FFTs पर लागू नहीं है, सही है? सिर्फ कनविक्शन / सहसंबंध?

@rgommers Bluestein एल्गोरिथ्म, मुख्य आकारों के लिए FFT की गति https://github.com/scipy/scipy/issues/4288 में किया जाता है, लेकिन आपको जटिल चिरागों की पूर्व-संगणना की आवश्यकता होती है, और जब आप रखते हैं तो सबसे अधिक कुशल होता है मेमोरी में चिरप करें और बार-बार इसे डेटा के चंक्स पर फिर से इस्तेमाल करें। तो मुझे यकीन नहीं है कि यह सुन्न के लिए अच्छा है और शायद इस आवेदन के लिए scipy.fftpack.czt के लिए स्थगित कर दिया जाए?

वैसे भी मुझे लगता है कि इसे https://github.com/numpy/numpy/issues/1177 के डुप्लिकेट के रूप में बंद किया जा सकता है? जब तक कि रेडर के एल्गोरिथ्म की तरह कुछ और ब्लूस्टीन से बेहतर है?

और @smcantab का मुद्दा अलग है?

endolith 16 फ़र॰ 2016

@endolith यह बहुत समय पहले था :) लेकिन हां, अब जब मैं इसे फिर से देखता हूं तो यह एक अलग मुद्दा लगता है। मेरे द्वारा बताई गई समस्या हालांकि अभी भी प्रासंगिक हो सकती है और मुझे इसके लिए pymbar में सुझाए गए वर्कअराउंड को लागू करना था।

smcantab 22 फ़र॰ 2016

FYI करें, मैं एक ऑडियो कॉन्फ्रेंस में किसी के पास भागा, जिसने मुझे यह उदाहरण दिखाया। यह पुन: पेश करना और चरम करना आसान है।

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

लंबाई 1 एफ 6: 16 मिलिसेकंड

लंबाई 1e6 + 3: 1 MINUTE और 42 SECONDS की चोरी

standarddeviant 18 अक्तू॰ 2017

फ़ीचर, बग नहीं। FFTPACK केवल "तेज़" है जब आकार कारक संख्या 2, 3, 4, 5 के उत्पाद के रूप में होता है। बड़े प्राइम साइज़ के लिए तेज़ एल्गोरिथम का उपयोग करने की लंबे समय से इच्छा रही है, लेकिन इसे लागू नहीं किया गया है। ध्यान दें कि 100003 अभाज्य है।

charris 18 अक्तू॰ 2017

मैं इसे "सुविधा" नहीं कहूंगा, लेकिन यह सामान्य है और बग नहीं है। :)

https://github.com/scipy/scipy/issues/4288 में ब्लूस्टिन का एल्गोरिथ्म है, लेकिन इसके लिए एक जटिल चिर की संगणना की आवश्यकता होती है, इसलिए यह देखने के लिए कुछ परीक्षण करने की आवश्यकता होगी कि यह किस प्रमुख आकार के अनुरूप है।

endolith 19 अक्तू॰ 2017

👍1

दिलचस्प। मुझे पता है कि मुख्य बात यह है कि जूलिया और मतलाब के लिए डिफ़ॉल्ट फफ्ट कार्यान्वयन में यह व्यवहार नहीं है। मैं उत्सुक हूं कि जूलिया कार्यान्वयन इस व्यवहार से बचने के लिए क्या करता है।

standarddeviant 19 अक्तू॰ 2017

जूलिया और मतलाब एफएफटीडब्ल्यू कहते हैं, जो हम इसके लाइसेंस के कारण नहीं कर सकते हैं।

charris 19 अक्तू॰ 2017

ध्यान दें कि FFTW के लिए पायथन बाइंडिंग हैं; pyFFTW बल्कि वर्तमान लगता है। यदि एफएफटी गति एक चिंता का विषय है, तो शायद यही रास्ता है। FFTPACK अपने दिन के लिए एक अच्छा कार्यान्वयन था, लेकिन कोड और हार्डवेयर आगे बढ़ गए हैं।

charris 19 अक्तू॰ 2017

@charris मैं निश्चित रूप से जानकारी की सराहना करता हूं और यह दुर्भाग्यपूर्ण है, लेकिन लाइसेंस के बारे में समझ में आता है।

standarddeviant 20 अक्तू॰ 2017

@standarddeviant आप FFTW का उपयोग करने के लिए सुन्न / चीर के ऊपर बंदर-पैच pyfftw भी कर सकते हैं

endolith 20 अक्तू॰ 2017

यह संख्या 1.17 में तय की जानी चाहिए।

mreineck 5 अप्रैल 2019

👍2

धन्यवाद @mreineck , समापन

rgommers 5 अप्रैल 2019

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Numpy: Numpy.fft.fft (Trac # 1266) में बहुत लंबे समय तक चलने वाली दौड़

सबसे उपयोगी टिप्पणी

सभी 19 टिप्पणियाँ

संबंधित मुद्दों