paint-brush
बिग ओ नोटेशन: यह क्या है और यह महत्वपूर्ण क्यों है?द्वारा@inovak
1,206 रीडिंग
1,206 रीडिंग

बिग ओ नोटेशन: यह क्या है और यह महत्वपूर्ण क्यों है?

द्वारा Ivan Novak4m2023/08/04
Read on Terminal Reader

बहुत लंबा; पढ़ने के लिए

बिग ओ के साथ संचार करना शुरुआती करियर विकासकर्ताओं के लिए पहले फेस-मेल्ट बदलावों में से एक है। यहां विशेष फोकस *सबसे खराब स्थिति में* जैसे-जैसे इनपुट का आकार बढ़ता है, समाधानों के बीच तुलना को सक्षम करना है। हम संक्षेप में संभावित समाधानों (कहने वाली बात: एल्गोरिदम*) के बारे में बात करने में सक्षम होना चाहते हैं।
featured image - बिग ओ नोटेशन: यह क्या है और यह महत्वपूर्ण क्यों है?
Ivan Novak HackerNoon profile picture
0-item

यह एक मजेदार बात है! बिग ओ के साथ संचार करना शुरुआती करियर विकासकर्ताओं के लिए पहले फेस-मेल्ट बदलावों में से एक है।


आइए देखें क्यों।


लेकिन सबसे पहले, एक गड्ढा बंद करो। क्या आपको ग्रेड स्कूल की वे बिल्कुल हास्यास्पद शब्द समस्याएं याद हैं?


सैली किराने की दुकान पर गई और 37 तरबूज़ खरीदे। उसके पास 20 डॉलर थे. प्रत्येक तरबूज़ की कीमत $0.70 है। घर पहुंचने पर सैली के पास कितना पैसा होगा?


क्या आप सोच में पड़ गए थे, "कैसे सैली घर पहुंचेगी? 37 तरबूज़ों के साथ?! $6.00 ख़रबूज़ों के लिए पर्याप्त जगह वाली उबर पाने के लिए पर्याप्त नहीं होंगे...सैली क्या कर रही है?"

मूर्ख सैली.


कुछ लोगों का कहना है कि इससे पेड़ों के लिए जंगल ख़त्म हो रहा है। मैं कहता हूं कि यह अभ्यास समस्याओं का निर्माण करने का एक बहुत ही आलसी तरीका है।


बिग ओ नोटेशन का उद्देश्य हमारे शिल्प की गुणवत्ता के बारे में अन्य लोगों से बात करने, वस्तुतः संवाद करने में सक्षम होना है। यहां विशेष फोकस सबसे खराब स्थिति में समाधानों के बीच तुलना को सक्षम करने पर है क्योंकि इनपुट का आकार बढ़ता है।


हम संक्षेप में संभावित समाधानों ( कहने वाली बात: एल्गोरिदम ) के बारे में बात करने में सक्षम होना चाहते हैं। यह एक महत्वपूर्ण बिंदु है: सार में । हमें अपने पास मौजूद डेटा की बिल्कुल भी परवाह नहीं है । जब हम इन विचारों के साथ खेलते हैं, तो हम सैद्धांतिक रूप से विशाल, लेकिन सीमित डेटासेट मानते हैं।


जब हम अपने पास मौजूद डेटा के बारे में सोचते हैं, तो यह ठोस तर्क होता है। जब हम बिग ओ नोटेशन के बारे में सोचते हैं, तो हम अमूर्त रूप में तर्क कर रहे होते हैं। ठोस तर्क पर वापस लौटना आसान है। यहीं हम जीवन का अधिकांश समय बिताते हैं। यह आसान, आमतौर पर स्पष्ट और आरामदायक है।

क्या मुझे अब सड़क पार करनी चाहिए? क्या कोई कार है? नहीं? ठीक है, पार करो.


अमूर्त में तर्क करते समय ऐसा न करें!

परिभाषाएँ, शीघ्रता से

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


ओ(1) - "निरंतर समय"

इससे कोई फर्क नहीं पड़ता कि इनपुट कितना बड़ा है, सिस्टम हमेशा उसी समय में परिणाम लौटाता है।


ओ(लॉग एन) - "लॉग टाइम"

जैसे ही समाधान (या एल्गोरिदम) इनपुट पर पुनरावृत्त होता है, प्रत्येक पुनरावृत्ति तेज हो जाती है!


ओ(एन) - "रैखिक समय"

जैसे-जैसे एल्गोरिथ्म पुनरावृत्त होता है, प्रत्येक पुनरावृत्ति में पिछले पुनरावृत्ति के समान ही समय लगता है।


ओ(एन लॉग एन) - यहां कोई फैंसी शब्दावली नहीं है

दिखाता है कि विचारों को जोड़ा जा सकता है (हाँ)। जैसे-जैसे हम पुनरावृति करते हैं, प्रत्येक पुनरावृत्ति धीमी होती जाती है लेकिन काफी धीरे-धीरे धीमी हो जाती है।


O(n^2) - "n वर्ग"

प्रत्येक पुनरावृत्ति के लिए, पुनरावृत्तियाँ बहुत तेज़ी से धीमी हो जाती हैं।


ओ(एन!) - "एन फैक्टोरियल"

प्रत्येक पुनरावृत्ति के लिए, पुनरावृत्तियाँ धीमी और बहुत तेज़ हो जाती हैं।


लक्ष्य "एन फैक्टोरियल" से जितना संभव हो सके दूर रहने की कोशिश करना है और कॉन्स्टेंट से ज्यादा खराब न होने की कोशिश करना है।


यह सब समझने के बाद, आइए अब अंतर को पाटने का प्रयास करें।

ठोस और अमूर्त सोच के बीच की खाई को पाटना

बिग ओ नोटेशन को समझना

बिग ओ नोटेशन का उपयोग किसी एल्गोरिदम (समाधान) के प्रदर्शन या जटिलता का वर्णन करने के लिए किया जाता है। यह इस बात की उच्च-स्तरीय समझ प्रदान करता है कि इनपुट का आकार बढ़ने पर एक एल्गोरिदम (समाधान) कैसा प्रदर्शन करेगा।


उदाहरण के लिए, O(n) जटिलता वाले एक एल्गोरिदम का रन टाइम इनपुट के आकार के साथ रैखिक रूप से बढ़ेगा।

ठोस बनाम अमूर्त सोच

चुनौती तब उत्पन्न होती है जब डेवलपर्स विशिष्ट डेटा के बारे में तर्क को एल्गोरिदम के बारे में तर्क समझने की गलती करते हैं। "लेकिन यह डेटा वास्तविक है" जैसे वाक्यांश इस भ्रम का संकेत दे सकते हैं।


हालाँकि वास्तविक डेटा के बारे में तर्क करना आपको आरंभ करने में मदद कर सकता है, लेकिन समाधान को वर्तमान इनपुट से अलग करना महत्वपूर्ण है।

गलतफहमी क्यों?

शुरुआती करियर डेवलपर्स बड़े पैमाने की समस्याओं के अनुभव की कमी या मौजूदा समस्या की बारीकियों में बहुत अधिक तल्लीन होने के कारण यह गलती कर सकते हैं। स्केलेबल समाधान बनाने के लिए ठोस विवरणों को अमूर्त जटिलता से अलग करना आवश्यक है।

व्यावहारिक परिणाम

जब इनपुट 100 या 100,000 गुना बढ़ जाता है, तो एल्गोरिदम का क्या होता है? एक अविश्वसनीय रूप से जटिल समाधान जटिलता बड़े डेटासेट के साथ ख़त्म हो सकती है।


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

सार में सोचना सीखना

समस्याओं के बारे में अमूर्त रूप से सोचने की क्षमता विकसित करने के लिए अभ्यास और मार्गदर्शन की आवश्यकता होती है। कुछ रणनीतियों में शामिल हैं:


  • अमूर्त मॉडल बनाना : समस्याओं को सामान्यीकृत तरीके से प्रस्तुत करना।


  • डेटा से अलग एल्गोरिदम का विश्लेषण करना : विशिष्ट डेटा बिंदुओं के बावजूद एल्गोरिदम कैसे व्यवहार करता है इसका मूल्यांकन करना।


  • स्केलिंग परिदृश्यों का निर्माण : कल्पना करना कि एल्गोरिदम इनपुट के विभिन्न आकारों के साथ कैसा प्रदर्शन करेगा।


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


समस्या जटिलता को एल्गोरिथम जटिलता से अलग करना सीखकर, डेवलपर्स आम नुकसान से बच सकते हैं और अकेले काम करते समय अपनी समस्या-समाधान क्षमताओं को बढ़ा सकते हैं और अन्य लोगों के साथ मिलकर काम करने की क्षमता में नाटकीय रूप से वृद्धि कर सकते हैं जिन्होंने इस तरह से संवाद करने का तरीका सीखने में समय लगाया है।


जटिल समस्याओं के लिए अक्सर जटिल समाधानों की आवश्यकता नहीं होती है। (सैली को शायद शुरुआत में 37 तरबूज़ों की ज़रूरत नहीं थी... वह 37 तरबूज़ों का क्या करेगी?!)