परिमित मात्रा कोड के लिए डेटा संरचनाएं: कक्षा बनाम सारणी

Question

मुझे Magnetohydrodynamics (MHD) के लिए एक परिमित मात्रा कोड लिखना होगा। मैंने पहले संख्यात्मक कोड लिखा है, लेकिन इस पैमाने पर नहीं। मैं सिर्फ यह पूछना चाहता था कि कक्षाओं के साथ डेटा संरचना (ऑब्जेक्ट ओरिएंटेड अप्रोच) का उपयोग करके या विभिन्न गुणों के लिए बस कई सरणियों का उपयोग करके, एक अच्छा विकल्प क्या होगा, गति, स्केलेबिलिटी आदि के संदर्भ में, मुझे अजगर में कोड लिखने की योजना है, और संख्यात्मक रूप से गहन भाग के लिए फोरट्रान का उपयोग करें।

अजगर में वर्ग के लिए एक उदाहरण होगा

class Cell:
   def __init__(self, x, y, z, U):

Arrays बस के रूप में परिभाषित किया जा सकता है

x[nx][ny][nz]
y[nx][ny][nz]
z[nx][ny][nz]
U[nx][ny][nz]

आदि।

Answer 1

सरल उत्तर: आधुनिक अजगर में प्रत्येक डेटा प्रकार एक वर्ग है, इसलिए औपचारिक रूप से आपके द्वारा प्रस्तावित दो समाधानों के बीच कोई अंतर नहीं है। (कृपया नई शैली की कक्षाओं का उपयोग करना याद रखें: क्लासिक कक्षाएं अप्रचलित हैं! Http://docs.python.org/2/reference/datamodel.html#new-style-and-classic-classes देखें )

अब सवाल यह होना चाहिए: मैं अजगर में एक कुशल डेटा संरचना कैसे व्यवस्थित करूं? कोई शक नहीं कि की एक सरणी के रूप में कोशिकाओं के आयोजन के विचार नहीं है class Cellउदाहरणों है जिस तरह से भी अक्षम। आप एक जटिल लिंक्ड सूची की तरह व्यवस्थित किए गए पॉइंटर्स और गैर-सन्निहित डेटा की गड़बड़ी को समाप्त करेंगे। आप निश्चित रूप से अपनी सूची में नई कोशिकाओं को आसानी से सम्मिलित करने की क्षमता रखते हैं: लेकिन क्या आपको इस सुविधा की आवश्यकता है? इसके विपरीत आपके पास गैर-सन्निहित डेटा संग्रहण होगा, और आपको प्रत्येक सेल को अप्रत्यक्ष के विभिन्न स्तरों तक पहुंच प्राप्त करनी होगी।

यदि आप अपने डेटा को एक numpy.ndarrayमेमोरी के रूप में व्यवस्थित करते हैं, तो डेटा मेमोरी-रिग्रेसिव है, और विभिन्न सेल तक पहुंच बस आपके मेमोरी ब्लॉक के माध्यम से स्ट्रैडिंग होती है: स्पेस एफिशिएंट (पॉइंटर्स के लिए कोई मेमोरी बर्बाद नहीं) और तेज ।

जैसा कि एथन द्वारा बताया गया है, OO अवधारणाओं का उपयोग किया जाना चाहिए, लेकिन उच्च स्तर पर, एक बार एक कुशल निम्न स्तर की डेटा संरचना को लागू किया गया है, आमतौर पर numpy.ndarray's के माध्यम से ।

OO प्रोग्रामिंग का मतलब उन तरीकों से डेटा को बाइंड करना है जो डेटा को खुद एब्सट्रैक्शन के उच्च स्तर पर संचालित करते हैं। (एक उदाहरण: मैंने एक FEM कोड लागू किया है जिसमें कठोरता मैट्रिक्स को एक वर्ग के रूप में परिभाषित किया गया था जिसमें विरल सुपर-नोडल चोल्स्की कारक के लिए एक विधि थी। पहला कार्यान्वयन कोर था: जब एक आउट-ऑफ-कोर कार्यान्वयन की आवश्यकता थी, तो यह था। डेटा संग्रहण को रेखांकित करने के लिए विरासत और न्यूनतम समायोजन के माध्यम से प्राप्त किया गया था । सुपर-नोडल चॉल्स्की कोड का लगभग 100% पुन: उपयोग किया गया था।)

एक अंतिम टिप्पणी, लेकिन महत्वपूर्ण: एक कुशल संख्यात्मक प्रक्रिया एक एल्गोरिथ्म की स्मार्ट मैपिंग और आपके कंप्यूटर कंप्यूटिंग संरचना के लिए एक डेटा संरचना का परिणाम है। यदि आप गलत डेटा संरचना से शुरू करते हैं, तो पूरी तरह से फिर से लिखे बिना दक्षता को पुनर्प्राप्त करने का कोई तरीका नहीं है ।

Comments

@EthanCoon अन्य उत्तर के लिए आपकी टिप्पणी के लिए धन्यवाद, जिसने मुझे अपना खुद का लिखने के लिए प्रेरित किया।

— स्टेफानो एम

Answer 2

मैं कुछ दिन पहले (पायथन में भी) इस पर विचार कर रहा था। व्यक्तिगत रूप से मुझे नहीं लगता कि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग हमेशा संख्यात्मक प्रोग्रामिंग के लिए एक अच्छा फिट है। आप समीकरणों को हल करने के बजाय कक्षाओं को डिजाइन करने से विचलित हो सकते हैं। मैं सरल कार्यों के साथ रहना पसंद करता हूं, और सुन्न के साथ आप अपने समीकरणों को सदिश कर सकते हैं, इसलिए आपको आवश्यक लाइनों की संख्या बहुत कम है। Numpy बहुत तेज़ है क्योंकि वास्तविक गणनाएँ C (या FORTRAN?) बैक एंड के साथ की जाती हैं।

मैं आपको क्या करने की सलाह दूंगा,

1. एक पायथन लिपि लिखें जो आपकी समस्या के सरलतम संभव संस्करण को सुन्न के साथ एक कार्यात्मक दृष्टिकोण का उपयोग करके हल करती है । उदाहरण के लिए, मनमानी इकाई में सब कुछ है और केवल 1 डी (या 2 डी) का प्रयास करें। यदि कोड गड़बड़ है तो यह इस स्तर पर पूरी तरह से ठीक है। महत्वपूर्ण बात यह है कि आप अपनी परियोजना के साथ आगे बढ़ रहे हैं।
2. एक बार आपके पास कुछ है जो काम करता है। पहचानें कि कोड कहाँ क्रिया है और अपवर्तक है। इस स्तर पर आप अपने कोड को सरल बनाने के बारे में विभिन्न विचारों के साथ खेल सकते हैं। हो सकता है कि ऐसे फ़ंक्शंस पेश करें जहां आप नोटिस करते हैं कि आप खुद को दोहरा रहे हैं। आप मूल संस्करण से तुलना कर सकते हैं ताकि आप जान सकें कि आप बग का परिचय नहीं दे रहे हैं।
3. तय करें कि ऑब्जेक्ट ओरिएंटेड एप्रोच कोड की जटिलता को और कम कर देगा।

मुख्य संदेश तब तक लिखना शुरू नहीं करता है जब तक कि आप पहले से ही समस्या को सरलतम तरीके से हल नहीं कर लेते हैं। यह केवल एक समस्या को हल करने का अनुभव प्राप्त करने के माध्यम से है जिसे आप जानेंगे कि आप अपने ऑब्जेक्ट ओरिएंटेड इंटरफ़ेस को कैसे परिभाषित करेंगे। यदि आप हाथ से पहले ऐसा करते हैं, तो यह बस रास्ते में आने की संभावना है।

Comments

मैं इस कथन से दृढ़ता से असहमत हूं कि OO संख्यात्मक प्रोग्रामिंग के लिए एक अच्छा फिट नहीं है, लेकिन जहां यह एक अच्छा फिट है, वह बहुत उच्च स्तर पर है। ओओ भौतिक विज्ञान मॉडल, मेष, सॉल्वर, आदि जैसी चीजों के लिए बहुत उपयोगी है, लेकिन कोशिकाओं के स्तर पर लगभग हमेशा अनुपयुक्त है।

— एथन कून

पोस्ट में मैं संख्यात्मक कोड के "समय से पहले ऑब्जेक्टिफ़िकेशन" के संभावित गड्ढे गिरने के बारे में चेतावनी देना चाहता था, खासकर जब एक शुरू हो रहा हो। मैं वस्तुओं का उपयोग करने के लिए प्रतिकूल नहीं हूं, मेरा तीसरा बिंदु देखें: यदि ऑब्जेक्ट जटिलता को कम कर सकते हैं तो वे एक अच्छा विचार हैं। मैं मानता हूं कि आपके द्वारा उद्धृत उदाहरण अच्छे उपयोग हैं, लेकिन उस बिंदु पर पहुंचने के लिए अनुभव की आवश्यकता होती है।

— बॉयफ्रेल