क्या कम्प्यूटेशनल जटिलता के बारे में कोई जानकारी नहीं है एक प्रोग्रामर होना एक समस्या है?

30

मुझे अपने विश्वविद्यालय में एक अभ्यास सौंपा गया है। मैं इसे घर ले गया और इसे हल करने के लिए एक एल्गोरिथ्म प्रोग्राम करने की कोशिश की, यह ग्राफ़ से संबंधित कुछ था, जुड़े घटकों को ढूंढ रहा था, मुझे लगता है।

फिर मैंने सबसे तुच्छ चीज़ बनाई जो मेरे दिमाग में आई और फिर अपने लेक्चरर को दिखाई। एक संक्षिप्त अवलोकन के बाद, उन्होंने माना कि मेरे समाधान की रनटाइम जटिलता आक्रामक थी और कुछ अधिक कुशल दिखाई गई। और प्रोग्रामर की एक परंपरा है, जो कम्प्यूटेशनल जटिलता (मैं उन में से एक था) पर कोई विचार नहीं है, तो क्या यह समस्या है कि क्या प्रोग्रामर को कम्प्यूटेशनल जटिलता पर कोई विचार नहीं है?

— बिली रुबीना
स्रोत

3

मॉडरेटर नोटिस : कृपया विस्तारित चर्चा के लिए टिप्पणियों का उपयोग न करें या उत्तर के उत्तर न दें। आप इस प्रश्न पर चर्चा करने के लिए चैट रूम का उपयोग कर सकते हैं ; पिछली टिप्पणियों को वहां स्थानांतरित कर दिया गया है।

— गिल्स एसओ- बुराई को रोकना '

4

आपका शीर्षक प्रोग्रामर कहता है, लेकिन आपका प्रश्न छात्र कहता है। आम तौर पर 'प्रोग्रामर' का मतलब 'पेशेवर प्रोग्रामर' होता है - तो क्या आप पूछ रहे हैं कि क्या कम्प्यूटेशनल जटिलता के ज्ञान के बिना पेशेवर प्रोग्रामर बनना एक समस्या है? या क्या यह एक प्रोग्रामिंग छात्र के लिए ठीक है कि उसे ज्ञान नहीं है? दो अलग-अलग प्रश्न हैं, भले ही यह पता चले कि उनके पास एक ही उत्तर है।

— corsiKa

42

हां, मैं कहूंगा कि कम्प्यूटेशनल जटिलता के बारे में कुछ जानना किसी भी गंभीर प्रोग्रामर के लिए जरूरी है। जब तक आप विशाल डेटा सेट के साथ काम नहीं कर रहे हैं तब तक आप जटिलता को नहीं जानते हुए भी ठीक रहेंगे, लेकिन यदि आप एक ऐसा प्रोग्राम लिखना चाहते हैं जो आपको गंभीर समस्याओं से निपटने की आवश्यकता है।

आपके विशिष्ट मामले में, कनेक्टेड घटकों को खोजने के आपके उदाहरण ने नोड्स तक के ग्राफ़ के लिए काम किया होगा । हालाँकि, यदि आपने नोड्स के साथ एक ग्राफ की कोशिश की, तो आपके लेक्चरर का एल्गोरिथ्म संभवत: 1 सेकंड में प्रबंधित हो जाएगा, जबकि आपके एल्गोरिथ्म में (जटिलता कितनी खराब है इसके आधार पर) 1 घंटा, 1 दिन, या शायद 1 अनंत काल भी लिया गया होगा। $100$ $100.000$

हमारे एल्गोरिदम पाठ्यक्रम में छात्रों की कुछ सामान्य गलती इस तरह से एक सरणी पर पुनरावृति करना है:

while array not empty
    examine first element of array
    remove first element from array

यह सबसे सुंदर कोड नहीं हो सकता है, लेकिन एक जटिल कार्यक्रम में प्रोग्रामर को इसके बारे में पता चले बिना ऐसा कुछ दिखाई दे सकता है। अब, इस कार्यक्रम में क्या समस्या है?

मान लीजिए कि हम इसे तत्वों के डेटा सेट पर चलाते हैं। निम्नलिखित कार्यक्रम की तुलना में, पूर्व कार्यक्रम धीमी गति से चलेगा । $100.000$ $50.000$

while array not empty
    examine last element of array
    remove last element from array

मुझे आशा है कि आप इस बात से सहमत होंगे कि आपके कार्यक्रम को गुना तेज करने के लिए ज्ञान होना शायद एक प्रोग्रामर के लिए एक महत्वपूर्ण बात है। दो कार्यक्रमों के बीच अंतर को समझने के लिए जटिलता सिद्धांत के बारे में कुछ बुनियादी ज्ञान और उस भाषा के विवरण के बारे में कुछ ज्ञान की आवश्यकता होती है जिसे आप प्रोग्रामिंग कर रहे हैं। $50.000$

मेरी छद्मकोड भाषा में, "किसी तत्व को एक सरणी से हटाने" से सभी तत्व तत्व के दाईं ओर शिफ्ट हो जाते हैं और बाईं ओर से एक स्थिति को हटा दिया जाता है। यह अंतिम तत्व ऑपरेशन को हटा देता है क्योंकि ऐसा करने के लिए हमें केवल 1 तत्व के साथ बातचीत करने की आवश्यकता होती है। पहले तत्व को हटाना क्योंकि पहले तत्व को निकालने के लिए हमें अन्य सभी तत्वों को बाईं ओर एक स्थिति में स्थानांतरित करना होगा। $O(1)$ $O(n)$ $n-1$

जटिलता में एक बहुत ही बुनियादी अभ्यास यह साबित करना है कि पहला कार्यक्रम करेगाऑपरेशन जबकि दूसरा प्रोग्राम केवलऑपरेशनका उपयोग करता है। यदि आपमें प्लग करते हैं, तो आपदेखेंगे कि एक प्रोग्राम दूसरे की तुलना में बहुत अधिक कुशल है। $\frac{1}{2}n^2$ $n$ $n=100.000$

यह सिर्फ एक खिलौना उदाहरण है, लेकिन पहले से ही इसे दो कार्यक्रमों के बीच अंतर बताने के लिए जटिलता की एक बुनियादी समझ की आवश्यकता है, और यदि आप वास्तव में एक अधिक जटिल कार्यक्रम को डीबग / ऑप्टिमाइज़ करने की कोशिश कर रहे हैं, तो यह गलती है इसे खोजने के लिए और भी अधिक समझ में आता है। जहां बग है। क्योंकि इस तरह से एलीमेंट में एलीमेंट से एलिमेंट को हटाने जैसी गलती को कोड में एब्स्ट्रैक्ट द्वारा बहुत अच्छे से छिपाया जा सकता है।

एक समस्या को हल करने के लिए दो दृष्टिकोणों की तुलना करते समय जटिलता की अच्छी समझ होना भी मदद करता है। मान लीजिए कि आप अपने आप में जुड़े घटकों की समस्या को हल करने के लिए दो अलग-अलग दृष्टिकोणों के साथ आए थे: उनके बीच निर्णय लेने के लिए यह बहुत उपयोगी होगा यदि आप उनकी जटिलता का अनुमान लगा सकते हैं (बेहतर)।

— टॉम वैन डेर ज़ैंडेन
स्रोत

10

"So long as you are not dealing with huge data sets you will be fine not knowing complexity"यह अक्सर सच होता है, लेकिन हमेशा ऐसा नहीं होता है। उदाहरण के लिए, एक O(n!)एल्गोरिथ्म अपेक्षाकृत छोटे डेटा सेट के लिए भी व्यवहार्य नहीं होगा। यदि आप एक O(n!)एल्गोरिथ्म का उपयोग करते हैं जहां आप O(n^2)अपने प्रोग्राम का उपयोग कर सकते थे, तो 10 के डेटा आकार पर निष्पादित करने के लिए 36,288 गुना अधिक समय लगेगा । 20 के डेटा आकार पर, आप 2.4 क्विंटलियन ऑपरेशन देख रहे हैं।

— रिहैब

1

मुझे लगता है कि @ रीराब का उदाहरण उत्तर में शामिल होना चाहिए। यह अधिक नाटकीय है और आपकी बात को निर्णायक रूप से सिद्ध करता है। और मुझे व्यक्तिगत रूप से इस तरह के एल्गोरिदम द्वारा काट लिया गया है, इससे पहले कि मैंने कम्प्यूटेशनल जटिलता सीख ली।

— सियुआन रेन

2

मुझे लगता है कि खेल में एक बड़ा मुद्दा है। यदि आप आसानी से नहीं जानते हैं तो आप उन कार्यों का चयन करें जहाँ इसकी आवश्यकता नहीं है। तो आप कह सकते हैं कि लगभग सभी सवालों के लिए मुझे एक्स के साथ जानने की आवश्यकता है, यह उपयोगी हो सकता है। इसलिए भले ही इसका क्रिटिकल जानना अभी भी अच्छा हो या अंत में आपके हाथ आ जाए।

— पूजा १५'१५

"दो कार्यक्रमों के बीच अंतर को समझना जटिलता सिद्धांत के बारे में कुछ बुनियादी ज्ञान की आवश्यकता है" - मुझे लगता है कि इस विशेष उदाहरण के लिए ऐसा नहीं है। आप इसे प्रोफाइल कर सकते हैं, निरीक्षण कर सकते हैं कि सभी समय "हटाए गए तत्व" में लिया गया है, पता है (जटिलता सिद्धांत को समझे बिना) कि अंतिम तत्व को हटाने से पहले हटाने से तेज है, परिवर्तन करें, और इसलिए कार्यक्रम को गति दें। जटिलता सिद्धांत को समझने का लाभ यह है कि यह आपको इस तरह की समस्याओं को कम कर देता है बिना प्रोफाइलिंग किए, ताकि आप "समय से पहले" अनुकूलन कर सकें।

— स्टीव जेसोप

.. और सामान्य तौर पर मुझे संदेह है कि जटिलता सिद्धांत के संदर्भ के बिना, एक या एक करके सभी या लगभग सभी व्यावहारिक उदाहरण हल किए जा सकते हैं। इस मामले में, यह जानना कि बहुत सारा डेटा कॉपी करना धीमा है ऐसा नहीं करने से, "जटिलता सिद्धांत" नहीं है। लेकिन निश्चित रूप से यह प्रोग्रामिंग (और किसी भी पेशे) में अभी भी उपयोगी है सिद्धांतों का एक अच्छा मानसिक मॉडल है जो आम तौर पर सामने आता है, क्योंकि आप इस तरह की समस्याओं का विश्लेषण, चर्चा कर सकते हैं और सिद्धांत के अनुसार एक समय में सिद्धांत के अनुसार नियमित रूप से कर सकते हैं।

— स्टीव जेसोप

26

यह टॉम वैन डेर ज़ैंडन के जवाब का खंडन है , जिसमें कहा गया है कि यह बहुत जरूरी है।

बात यह है कि, ज्यादातर बार, 50.000 बार धीमी गति प्रासंगिक नहीं होती है (जब तक कि आप Google पर काम नहीं करते हैं)।

यदि आप जो ऑपरेशन करते हैं वह एक माइक्रोसेकंड लेता है या यदि आपका एन कभी एक निश्चित सीमा से ऊपर नहीं है (आजकल किए गए कोडिंग का एक उच्च भाग) तो यह कभी भी नहीं होगा। उन मामलों में कम्प्यूटेशनल जटिलता के बारे में सोचना आपको केवल समय बर्बाद करेगा (और सबसे अधिक संभावना पैसा)।

कम्प्यूटेशनल जटिलता यह समझने का एक उपकरण है कि क्यों कुछ धीमा या खराब हो सकता है, और इसे कैसे सुधारना है, लेकिन अधिकांश समय पूरा ओवरकिल है।

मैं अब पांच साल से अधिक समय तक एक पेशेवर प्रोग्रामर रहा हूं और मुझे कभी भी कम्प्यूटेशनल जटिलता के बारे में सोचने की जरूरत नहीं पड़ी है जब लूप ओ (एम * एन) के अंदर लूपिंग होती है क्योंकि हमेशा ऑपरेशन वास्तव में तेज या एम और एन होता है। छोटे।

आम तौर पर उपयोग किए जाने वाले कामों को समझने के लिए कहीं अधिक महत्वपूर्ण, आमतौर पर उपयोग की जाने वाली और कठिन चीजें हैं (थ्रेडिंग और प्रोफाइलिंग प्रदर्शन क्षेत्र में अच्छे उदाहरण हैं)।

बेशक, कुछ चीजें हैं जो आप कम्प्यूटेशनल जटिलता को समझने के बिना कभी नहीं कर पाएंगे (उदाहरण के लिए: एक शब्दकोश में एनाग्राम ढूंढना), लेकिन अधिकांश समय आपको इसकी आवश्यकता नहीं है।

— claudio495h
स्रोत

3

अपनी बात पर विस्तार करने के लिए, ऐसे मामले हैं जहां कम्प्यूटेशनल जटिलता पर बहुत अधिक जोर आपको भटका सकता है। उदाहरण के लिए, ऐसी परिस्थितियां हो सकती हैं जहां "बेहतर" एल्गोरिदम वास्तव में छोटे इनपुट के लिए धीमा है। प्रोफाइलर सत्य का अंतिम स्रोत है।

— केविन क्रुमविडेड

2

@ केविन क्रुमविडे, मैं आपसे पूरी तरह सहमत हूं कि एक तुच्छ डेटा सेट के लिए एक प्रकार का अनुकूलन ओवरकिल है। लेकिन यह भी दिखाता है कि कम से कम जटिलता की समझ होना अभी भी महत्वपूर्ण है। समझ वह है जो आपको यह निर्णय लेने के लिए प्रेरित करेगी कि एक बुलबुला प्रकार कुछ अन्य, अधिक जटिल, एल्गोरिदम के विपरीत उपयुक्त है।

— केंट ए।

4

जब आप जानते हैं कि डेटा सेट सभी मामलों में छोटा है तो आप इस तरह की चीज़ से दूर हो सकते हैं। आपको छोरों के भीतर कहे जाने वाले सामान में अतिरिक्त जटिलता से बहुत सावधान रहना होगा, हालांकि - बहुत समय पहले मैंने एक मिनट के रनटाइम को दूसरी तरह से नहीं काटा। मैंने एक बार O (n ^ 8) समस्या का भी सामना किया है (डेटा सत्यापन।) देखभाल के बहुत सारे इसे 12 घंटे तक मिल गया।

— लोरेन Pechtel

7

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

— 19

4

समयपूर्व अनुकूलन सभी बुराई की जड़ है, लेकिन समय से पहले निराशावाद नाराज उपयोगकर्ताओं के कम से कम एक अच्छे सौदे की जड़ है। आपको पुनरावृत्ति संबंध को हल करने में सक्षम होने की आवश्यकता नहीं हो सकती है, लेकिन यदि आप बहुत कम से कम, ओ (1), ओ (एन) और ओ (एन ^ 2) के बीच अंतर बताने में सक्षम नहीं हैं, खासकर जब आप 'छोरों को घोंसला बनाना, किसी को बाद में गंदगी को साफ करना होगा। स्रोत: जिन गंदगी को मुझे बाद में साफ करना पड़ा। एक कारक 50.000 इतना बड़ा है कि आपको बेहतर पता था कि क्या आप अभी भी बाद में खर्च कर सकते हैं , जब आपके इनपुट बढ़ गए हैं।

— जेरोइन मोस्टर्ट

14

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

कहने के बावजूद, मैं स्वयं सिखाया जाता हूं। जब तक मैंने कुछ साल पहले साक्षात्कार शुरू नहीं किया तब तक मुझे ओ नोटेशन का सामना नहीं करना पड़ा। यह साक्षात्कार के दौरान मेरे पेशेवर काम EXCEPT में कभी नहीं आया। इसलिए मुझे साक्षात्कार में उस प्रश्न को संभालने के लिए मूल बातें सीखना पड़ा।

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

संयोग से, मैंने हाल ही में एक फ्रंट एंड वेब डेवलपर भूमिका के लिए साक्षात्कार किया। उन्होंने मुझसे एक प्रश्न पूछा, जहां उत्तर के लिए कम्प्यूटेशनल जटिलता और लघुगणक के ज्ञान की आवश्यकता थी। मैं बीस साल पहले से पर्याप्त गणित को याद करने में कामयाब रहा, ताकि इसका जवाब कम या ज्यादा सही तरीके से दिया जा सके, लेकिन यह थोड़ा परेशान करने वाला था। मुझे कभी भी किसी भी फ्रंट एंड डेवलपमेंट में लॉगरिदम का उपयोग नहीं करना पड़ा है।

आप सौभाग्यशाली हों!

— स्कॉट शेफर
स्रोत

2

तो, आपका जवाब "हाँ" है?

— राफेल

6

टीएल; डीआर: "हां"। हालाँकि, मेरे अनुभव में आप नौकरी पर रखने के बाद अधिकांश नौकरियों में कम्प्यूटेशनल जटिलता के बारे में बात नहीं करेंगे। हां, अपने डेटा संरचनाओं और उनके प्रदर्शन को जानें, लेकिन सिर्फ यह जानते हुए कि एक एल्गोरिथ्म हे (एन) या जो भी एक अच्छा प्रोग्रामर नहीं बनाता है। बेहतर है कि जल्दी से अच्छा कोड लिखें और बाद में हॉट स्पॉट का अनुकूलन करें। प्रदर्शन की तुलना में अधिकांश कोड के लिए पठनीयता और स्थिरता आमतौर पर अधिक महत्वपूर्ण होती है।

— स्कॉट शेफर

3

मुझे लगता है कि ऐसा हो सकता है कि कॉरपोरेट सेटिंग में जटिलता आती है, लेकिन कंपनियों के लिए पहली वास्तविक चिंता शिपिंग है : यदि यह काम करता है, तो यह काफी अच्छा है, जब तक कि ऐप को बेहतर बनाने के लिए उपलब्ध बजट नहीं है, या एक ग्राहक गरीबों की शिकायत करने के लिए वापस आता है प्रदर्शन। एडहॉक प्रोजेक्ट्स के लिए b2b स्थितियों में, यह संभवतः काफी असामान्य है। बी 2 सी में, या अत्यधिक प्रतिस्पर्धी बाजारों में (शेल्फ उत्पादों से), यह संभवतः अधिक बार आएगा, नए किराए के लिए प्रवेश बार को बढ़ाने के प्रत्यक्ष प्रभाव के साथ।

— 15

4

@didierc "काफी अच्छा" भी वही है जो हर समय चीजों को तोड़ता है।

— राफेल

1

@didierc 1) ठीक है, सीएस में ठोस पृष्ठभूमि वाले लोगों करते (उम्मीद), क्या सही है और क्या नहीं है, जबकि तदर्थ समस्या समाधानकर्ताओं "सरल" गलतियों प्रतिबद्ध हो सकता है के लिए एक अच्छा अंतर्ज्ञान है। यह सुनिश्चित करना कि मल्टीप्लाई संकलन के बाद निष्पादन वही है जो निर्दिष्ट था कि अत्यधिक गैर-तुच्छ है, और एक अनसुलझी समस्या को दूर करता है। 2) नहीं ।

— राफेल

9

प्रश्न काफी व्यक्तिपरक है, इसलिए मुझे लगता है कि इसका उत्तर निर्भर करता है ।

इससे कोई फर्क नहीं पड़ता कि यदि आप कम मात्रा में डेटा के साथ काम करते हैं। इन मामलों में, आमतौर पर जो भी आपकी भाषा की मानक लाइब्रेरी प्रदान करता है, उसका उपयोग करना ठीक है।

हालांकि, जब आप बड़ी मात्रा में डेटा के साथ सौदा करते हैं, या किसी अन्य कारण से आप जोर देते हैं कि आपका कार्यक्रम तेज है, तो आपको कम्प्यूटेशनल जटिलता को समझना होगा। यदि आप नहीं करते हैं, तो आप कैसे जानते हैं कि किसी समस्या को कैसे हल किया जाना चाहिए, या कितनी जल्दी इसे हल करना संभव है? लेकिन सिर्फ सिद्धांत को समझना वास्तव में अच्छा प्रोग्रामर होने के लिए पर्याप्त नहीं है। अत्यंत तेज़ कोड का उत्पादन करने के लिए, मेरा मानना है, आपको यह भी समझना होगा कि आपकी मशीन कैसे काम करती है (कैश, मेमोरी लेआउट, इंस्ट्रक्शन सेट), और आपके कंपाइलर क्या करते हैं (कंपाइलर अपना सर्वश्रेष्ठ करते हैं, लेकिन सही नहीं हैं)।

संक्षेप में, मुझे लगता है कि जटिलता को समझना स्पष्ट रूप से आपको एक बेहतर प्रोग्रामर बनाता है।

— Juho
स्रोत

1

मुझे लगता है कि आपके पास आम तौर पर सही विचार है, लेकिन "व्यक्तिपरक" इस मुद्दे का पर्याप्त रूप से वर्णन नहीं करता है; "परिस्थितिजन्य" एक बेहतर शब्द होगा। हालांकि, कोई भी बहुत धीमे प्रोग्राम लिख सकता है जो बहुत अधिक डेटा पर काम नहीं करता है। मैंने हाल ही में गणित पर एक प्रश्न का उत्तर दिया। बहुपद प्रतिनिधित्व / भंडारण के बारे में। आमतौर पर इसमें बहुत कम मात्रा में डेटा शामिल होता है जैसे ~ 1000-टर्म पॉलीनोमियल विशिष्ट होते हैं; फिर भी कार्यान्वयन के आधार पर प्रदर्शन में भारी वास्तविक-दुनिया के अंतर (सैकड़ों या हजारों सेकंड बनाम एक गुणा के लिए) होते हैं।

— फिज़ा

4

यह निश्चित रूप से एक समस्या है अगर कोई महत्वपूर्ण एल्गोरिदम विकसित कर रहा है जो एल्गोरिथ्म जटिलता को नहीं समझता है। एक एल्गोरिथ्म के उपयोगकर्ता आमतौर पर कार्यान्वयन की अच्छी गुणवत्ता पर भरोसा करते हैं जिसमें अच्छी प्रदर्शन विशेषताएं होती हैं। जबकि एल्गोरिथ्म की प्रदर्शन विशेषताओं में जटिलता का एकमात्र योगदान नहीं है, यह एक महत्वपूर्ण है। कोई ऐसा व्यक्ति जो एल्गोरिथम जटिलता को नहीं समझता है, उपयोगी प्रदर्शन विशेषताओं के साथ एल्गोरिदम विकसित करने की संभावना कम है।

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

फिर ऐसे डेवलपर हैं जो (बेहतर विवरण के लिए) गैर-एल्गोरिदम संबंधी चिंताओं पर ध्यान केंद्रित करते हैं। उदाहरण के लिए, वे सहज उपयोगकर्ता इंटरफेस विकसित करने पर ध्यान केंद्रित कर सकते हैं। ऐसे डेवलपर्स को अक्सर एल्गोरिथ्म जटिलता के बारे में चिंता करने की आवश्यकता नहीं होगी, हालांकि, फिर से, वे उच्च गुणवत्ता के लिए विकसित किए जा रहे पुस्तकालयों या अन्य कोड पर भरोसा कर सकते हैं।

— लूटना
स्रोत

3

यह निर्भर करता है, लेकिन उस डेटा की मात्रा पर नहीं, जिसके साथ आप काम कर रहे हैं, लेकिन जिस तरह का काम आप करते हैं, आपके द्वारा विकसित किए जाने वाले प्रोग्राम पर।

आइए प्रोग्रामर को कॉल करें जो वैचारिक जटिलता के बारे में नहीं जानता है प्रोग्रामर।

नोबिश प्रोग्रामर कर सकता है:

बड़े डेटा डेटाबेस विकसित करें - उसे यह जानने की ज़रूरत नहीं है कि यह अंदर कैसे काम करता है, उसे सभी को पता होना चाहिए कि विकासशील डेटाबेस के बारे में नियम हैं। वह चीजों को जानता है जैसे: क्या अनुक्रमित किया जाना चाहिए, ... जहां डेटा में अतिरेक बनाना बेहतर है, जहां यह नहीं है ...
गेम बनाएं - उसे बस यह अध्ययन करना है कि कुछ गेम इंजन कैसे काम करते हैं और इसके प्रतिमानों का पालन करते हैं, गेम और कंप्यूटर ग्राफिक्स काफी बड़ी डेटा समस्याएं हैं। सिंगल पिक्चर / फ्रेम के लिए 1920 * 1080 * 32bit = cca 7.9MB पर विचार करें ... @ 60 FPS यह कम से कम 475MB / s है। विचार करें, कि फुलस्क्रीन तस्वीर की सिर्फ एक अनावश्यक प्रति लगभग 500MB मेमोरी थ्रूपुट प्रति सेकंड बर्बाद होगी। लेकिन, उसे इस बारे में ध्यान रखने की आवश्यकता नहीं है, क्योंकि वह केवल इंजन का उपयोग करता है!

नोबिश प्रोग्रामर को ऐसा नहीं करना चाहिए:

बहुत बार उपयोग किए जाने वाले जटिल कार्यक्रमों का विकास करें, इसके साथ काम करने वाले डेटा के आकार की कोई बात नहीं है, ... उदाहरण के लिए, छोटे डेटा विकास के दौरान अनुचित समाधान के ध्यान देने योग्य प्रभाव का कारण नहीं होगा, क्योंकि यह संकलन समय की तुलना में धीमा होगा, आदि, इसलिए, 0.5 एक साधारण प्रोग्राम के लिए सेकंड नोबिश प्रोग्रामर के नजरिए से बहुत अच्छा नहीं है, खैर, सर्वर सर्वर पर विचार करें, जो इस कार्यक्रम को प्रति सेकंड बीस बार चलाता है। यह उस भार को बनाए रखने में सक्षम होने के लिए 10 करोड़ की आवश्यकता होगी!
एम्बेडेड उपकरणों के लिए कार्यक्रम विकसित करना। एंबेडेड डिवाइस छोटे डेटा के साथ काम करते हैं, लेकिन उन्हें जितना संभव हो उतना कुशल होने की आवश्यकता होती है, क्योंकि अनावश्यक संचालन अनावश्यक बिजली का विस्फोट करते हैं

तो, नोबल प्रोग्रामर ठीक है, जब आप सिर्फ तकनीकों का उपयोग करना चाहते हैं। इसलिए, जब नए समाधानों, कस्टम प्रौद्योगिकियों आदि के विकास की बात आती है, तो यह बेहतर है कि नोबिश प्रोग्रामर को न रखें।

हालांकि, अगर कंपनी नई तकनीकों का विकास नहीं करती है, तो पहले से ही बनाए गए उपयोग करता है। कुशल और प्रतिभाशाली प्रोग्रामर को काम पर रखना प्रतिभा की बर्बादी होगी। यही बात लागू होती है, यदि आप नई तकनीकों पर काम नहीं करना चाहते हैं और आप पहले से बने फ्रेमवर्क का उपयोग करके ग्राहकों के विचारों को डिजाइन और कार्यक्रमों में डाल रहे हैं, तो यह आपके समय की बर्बादी है, कुछ सीखने के लिए जिनकी आपको कभी आवश्यकता नहीं होगी, सिवाय अगर यह आपका शौक है और आप तार्किक चुनौतियों को पसंद करते हैं।

— kravemir
स्रोत

1

इस उत्तर को बेहतर बनाया जा सकता है यदि यह एक अधिक तटस्थ लेबल का उपयोग करता है, या कोई भी लेबल बिल्कुल नहीं है, अन्य उत्तर की तरह जो "अक्षम प्रोग्रामर" शब्द का उपयोग करता है।

— मोबी डिस्क

1

मुझे यकीन नहीं है कि आप "वैचारिक जटिलता" से क्या मतलब है। मेरा अनुभव यह है कि जो लोग पेड़ों या हैशटेबल्स के बारे में पर्याप्त नहीं जानते हैं, वे एक बड़े डेटाबेस को इंडेक्स (कैसे करें) के बारे में बुद्धिमान निर्णय नहीं ले सकते हैं।

— फिजा

3

मैं यहाँ एक उत्तर लिखने में कुछ संकोच कर रहा हूँ, लेकिन जब से मैंने खुद को कई अन्य लोगों पर नाइटपैकिंग पाया है '[मेरी कुछ टिप्पणी चैट में स्थानांतरित हो गई], यहां बताया गया है कि मैं इसे कैसे देखता हूं ...

कंप्यूटिंग में बहुत सी चीजों के ज्ञान के स्तर / डिग्री हैं (और इस शब्द से मेरा मतलब है कि सूचना प्रौद्योगिकी के साथ कंप्यूटर विज्ञान का संघ)। अभिकलन जटिलता निश्चित रूप से एक विशाल क्षेत्र है (क्या आप जानते हैं कि OptP क्या है? या Abiteboul-Vianu प्रमेय क्या कहता है?) और यह भी बहुत गहराई से मानता है: CS डिग्री वाले अधिकांश लोग विशेषज्ञ प्रमाणों का उत्पादन नहीं कर सकते हैं जो शोध में जाते हैं? कम्प्यूटेशनल जटिलता में प्रकाशन।

$n^2$

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

और एक और बात यह है कि कम्प्यूटेशनल जटिलता को जानने से आप स्वचालित रूप से कार्यक्रमों के अनुकूलन में अच्छा नहीं कर पाएंगे; आपको अधिक स्थानीय वास्तुकला से संबंधित सामान को समझना होगा जैसे कि कैश लोकेलिटी, [कभी-कभी] पाइपलाइनिंग, और आजकल समानांतर / मल्टी-कोर प्रोग्रामिंग भी; उत्तरार्द्ध की अपनी जटिलता सिद्धांत और व्यावहारिक विचार दोनों हैं; 2013 के एसओएसपी पेपर से उत्तरार्द्ध का स्वाद "हर लॉकिंग स्कीम की अपनी पंद्रह मिनट की प्रसिद्धि है। नौ लॉकिंग योजनाओं में से कोई भी हम सभी लक्ष्य आर्किटेक्चर या वर्कलोड पर किसी भी अन्य से लगातार बेहतर प्रदर्शन करते हैं। इस प्रकार लॉक एल्गोरिथ्म को हार्डवेयर प्लेटफॉर्म और अपेक्षित कार्यभार के आधार पर चुना जाना चाहिए। "

— सीटी
स्रोत

1

लंबे समय में, एक बेहतर एल्गोरिथ्म विकसित करना या खोजना आमतौर पर प्रदर्शन-संवेदनशील बिट्स के लिए प्रोग्रामिंग भाषा को बदलने की तुलना में अधिक फायदेमंद होता है। मैं आपसे सहमत हूं कि जटिलता और समय से पहले अनुकूलन की समझ की कमी के बीच एक मजबूत संबंध है - क्योंकि वे आमतौर पर अनुकूलन के लिए कम प्रदर्शन-संवेदनशील बिट्स को लक्षित करते हैं।

— रोब

1

व्यवहार में, (अनजाने में) श्लेमील द पेंटर के एल्गोरिदम ओ (एन ^ 2) छांटने की तुलना में बहुत अधिक हैं।

— पीटर मोर्टेंसन

-1

यदि आप बड़े-ओ नहीं जानते हैं तो आपको इसे सीखना चाहिए। यह मुश्किल नहीं है, और यह वास्तव में उपयोगी है। खोज और छँटाई से शुरू करें।

मैं ध्यान देता हूं कि बहुत सारे उत्तर और टिप्पणियाँ प्रोफाइलिंग की सलाह देते हैं , और उनका मतलब लगभग हमेशा एक प्रोफाइलिंग टूल का उपयोग करना होता है ।

परेशानी यह है कि प्रोफाइलिंग टूल सभी के नक्शे में इस बात के संदर्भ में हैं कि वे आपको प्रभावी बनाने के लिए कितने प्रभावी हैं। यहाँ मैंने सूचीबद्ध किया है और उन गलत धारणाओं की व्याख्या की है जो प्रोफाइलर्स से ग्रस्त हैं।

परिणाम यह है कि कार्यक्रम, यदि वे एक अकादमिक अभ्यास से बड़े हैं, तो सोते हुए दिग्गज शामिल हो सकते हैं , यहां तक कि सबसे अच्छा स्वचालित प्रोफाइलर को उजागर नहीं किया जा सकता है। यह पोस्ट कुछ उदाहरण दिखाती है कि प्रोफाइलर्स से प्रदर्शन की समस्याएं कैसे छिप सकती हैं।

लेकिन वे इस तकनीक से छिप नहीं सकते ।

— माइक डनलवे
स्रोत

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

— राफेल

@ राफेल: मैं एक अलग दृष्टिकोण की वकालत नहीं करता - यह orthogonal.Big-O एल्गोरिदम को समझने के लिए बुनियादी ज्ञान है, जबकि गैर-खिलौना सॉफ़्टवेयर में प्रदर्शन समस्याओं का पता लगाना कुछ ऐसा है जिसे आप कोड लिखे जाने और चलाने के बाद करते हैं, पहले नहीं। (कभी-कभी शिक्षाविदों को यह पता नहीं होता है, इसलिए वे अच्छे से अधिक नुकसान कर रहे हैं, इसलिए उन्हें सिखाना जारी रखते हैं।) ऐसा करने में, आपको पता चल सकता है कि समस्या O (n * n) एल्गोरिथ्म का उपयोग है या नहीं, इसलिए आपको चाहिए कि पहचान करने में सक्षम हो। (और बिग-ओ एल्गोरिदम की एक गणितीय रूप से परिभाषित संपत्ति है, एक अलग विषय नहीं है।)

— माइक डनलैवी

"और बिग-ओ एल्गोरिदम की एक गणितीय रूप से परिभाषित संपत्ति है, एक अलग विषय नहीं है।" - यह गलत है, और खतरनाक रूप से ऐसा है। "बिग-ओह" कार्यों के वर्गों को परिभाषित करता है ; प्रति se, इसका एल्गोरिदम से कोई लेना देना नहीं है।

— राफेल

आइए हम इस चर्चा को चैट में जारी रखते हैं ।

— राफेल