बेहतर निर्देशांक

Question

मैं अजगर के लिए एक सी ++ वैज्ञानिक आवेदन पोर्टिंग कर रहा हूँ के भंडारण के लिए एक टपल या numpy सरणी का उपयोग करें और के रूप में मैं अजगर करने के लिए नया हूँ, कुछ समस्याओं का मेरे मन के लिए आते हैं:

1) मैं परिभाषित करने कर रहा हूँ एक वर्ग जिसमें निर्देशांक (x, y) होंगे। इन मानों को कई बार एक्सेस किया जाएगा, लेकिन वे केवल क्लास इंस्टेंटेशन के बाद पढ़े जाएंगे। क्या स्मृति में और समय के अनुसार दोनों में एक टुपल या एक numpy सरणी का उपयोग करना बेहतर है?

2) कुछ मामलों में, इन निर्देशांकों का उपयोग जटिल संख्या बनाने के लिए किया जाएगा, जटिल कार्य पर मूल्यांकन किया जाएगा, और इस समारोह का वास्तविक हिस्सा उपयोग किया जाएगा। यह मानते हुए कि इस कार्य के वास्तविक और जटिल भागों को अलग करने का कोई तरीका नहीं है, और वास्तविक भाग को अंत में उपयोग करना होगा, शायद स्टोर करने के लिए सीधे जटिल संख्याओं का उपयोग करना बेहतर है (x, y)? पाइथन में जटिल से वास्तविक में परिवर्तन के साथ ओवरहेड कितना बुरा है? सी ++ में कोड इन परिवर्तनों में से बहुत कुछ करता है, और यह उस कोड में एक बड़ी मंदी है।

3) कुछ समन्वय परिवर्तन भी करना होगा, और समन्वय के लिए एक्स और वाई मानों को अलग से एक्सेस किया जाएगा, परिवर्तन किया जाएगा, और परिणाम लौटाया जाएगा। समन्वय परिवर्तन जटिल विमान में परिभाषित किए गए हैं, इसलिए जटिल चर पर भरोसा करने से सीधे घटक x और y का उपयोग करने के लिए अभी भी तेज़ है?

धन्यवाद

Answer 1

स्मृति खपत के मामले में, numpy arrays Python tuples की तुलना में अधिक कॉम्पैक्ट हैं। एक numpy सरणी स्मृति के एक संगत ब्लॉक का उपयोग करता है। Numpy सरणी के सभी तत्व घोषित प्रकार (जैसे 32-बिट या 64-बिट फ्लोट) होना चाहिए। एक पायथन ट्यूपल आवश्यक रूप से स्मृति के एक संगत ब्लॉक का उपयोग नहीं करता है, और ट्यूपल के तत्व मनमाने ढंग से पाइथन ऑब्जेक्ट्स हो सकते हैं, जो आमतौर पर numpy संख्यात्मक प्रकारों की तुलना में अधिक स्मृति का उपभोग करें।

तो यह समस्या numpy के लिए एक हाथ से नीचे जीत है, (मानते हैं कि सरणी के तत्वों को एक numpy संख्यात्मक प्रकार के रूप में संग्रहीत किया जा सकता है)।

गति के मुद्दे पर, मुझे लगता है कि विकल्प इस सवाल पर उबालता है, "क्या आप अपना कोड सदिशित कर सकते हैं?"

यही है, क्या आप अपनी गणनाओं को तत्वों के अनुसार पूरे सरणी पर किए गए संचालन के रूप में व्यक्त कर सकते हैं।

यदि कोड वेक्टरकृत किया जा सकता है, तो numpy पाइथन tuples की तुलना में अधिक तेज़ होगा। (एकमात्र मामला मैं कल्पना कर सकता हूं कि यह कहां नहीं हो सकता है, यह है कि यदि आपके पास बहुत छोटे tuples थे। इस मामले में numpy arrays बनाने और numpy आयात करने की एक बार लागत का ओवरहेड वेक्टरकरण के लाभ डूब सकता है।)

कोड का एक उदाहरण है कि हो सकता है अगर आपके गणना, एक सरणी z में कहते हैं में, पहले जटिल संख्या, देख एक गणना जो एक पूर्णांक सूचकांक idx, तो z[idx] पुन: प्राप्त करने, एक गणना कर का उत्पादन कर रही शामिल vectorized नहीं किया जा सका उस नंबर पर, जो अगली अनुक्रमणिका idx2 उत्पन्न करता है, फिर z[idx2] आदि पुनर्प्राप्त करता है। इस प्रकार की गणना वेक्टरिज़ेबल नहीं हो सकती है।इस मामले में, आप पाइथन टुपल्स का भी उपयोग कर सकते हैं, क्योंकि आप numpy की ताकत का लाभ उठाने में सक्षम नहीं होंगे।

मैं जटिल संख्या के असली/काल्पनिक भागों तक पहुंचने की गति के बारे में चिंता नहीं करता। मेरा अनुमान है कि वेक्टरेशन का मुद्दा सबसे अधिक संभावना निर्धारित करेगा कि कौन सी विधि तेज है। (हालांकि, वैसे, numpy जटिल संख्याओं की एक सरणी को जटिल सरणी पर आगे बढ़कर, हर दूसरे फ्लोट को छोड़कर, और परिणाम को फ्लोट के रूप में देखकर जटिल संख्याओं को बदल सकता है। इसके अलावा, वाक्यविन्यास मृत सरल है: यदि z है । एक जटिल numpy सरणी, तो z.real एक नाव numpy सरणी के रूप में वास्तविक भागों है यह विशेषता लुकअप की एक सूची समझ का उपयोग करने का शुद्ध पायथन दृष्टिकोण की तुलना में कहीं तेजी से किया जाना चाहिए:। [z.real for z in zlist])

बस जिज्ञासा से बाहर

, क्या है सी ++ कोड को पायथन में पोर्ट करने का आपका कारण?

Answer 2

एक अतिरिक्त आयाम के साथ एक numpy सरणी कम से कम के रूप में तेजी से स्मृति उपयोग में तंग है, और tuples के एक numpy सरणी के रूप में !,; जटिल संख्या कम से कम उतनी ही अच्छी या बेहतर होती है, जिसमें आपके तीसरे प्रश्न भी शामिल हैं। बीटीडब्लू, आपने देखा होगा कि - आपके बाद के प्रश्नों के बाद पूछे जाने वाले प्रश्नों को बहुत कुछ मिल रहा था - आप गिरावट दे रहे थे: कारण का हिस्सा इसमें कोई संदेह नहीं है कि पूछना तीन प्रश्नों के भीतर प्रश्न उत्तरदाताओं को बंद कर देते हैं। क्यों न सिर्फ एक प्रश्न पूछें? ऐसा नहीं है कि आप प्रश्नों या किसी भी चीज़ के लिए शुल्क लेते हैं, आपको पता है ...! -)