एल्गोरिदम डिजाइन करने के अभ्यास के लिए एल्गोरिदम की असममित जटिलता की व्याख्या करना

Question

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

व्यवहार में, क्या जरूरत है एक एल्गोरिथ्म जो एक परिमित (हालांकि संभवतः बहुत बड़ी) उदाहरणों की संख्या पर तेजी से काम करेगा।

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

हम असममित जटिलता का उपयोग क्यों करते हैं? व्यवहार में एल्गोरिदम के डिजाइन से संबंधित ये विषम विश्लेषण कैसे करते हैं?

Comments

एक और प्रासंगिक सवाल यह है: हम निरंतर कारकों को अनदेखा क्यों करते हैं ?

— राफेल

Answer 1

दिलचस्प सवाल यह है: विकल्प क्या है? केवल एक अन्य विधि जो मुझे पता है कि परीक्षण / बेंचमार्किंग है। हम एल्गोरिदम को प्रोग्राम करते हैं, उन्हें परिमित इनपुट सेट (परिणामों के प्रतिनिधि) पर चलाते हैं और परिणामों की तुलना करते हैं। इसके साथ कुछ समस्याएं हैं।

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

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

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

कुछ हद तक अभ्यास करने के लिए अंतर को बंद करने के लिए औपचारिक, सैद्धांतिक सिद्धांत हैं। उदाहरण हैं

• स्मृति पदानुक्रम पर विचार (और अन्य I / O),
• औसत मामले का विश्लेषण (जहां उपयुक्त हो),
• व्यक्तिगत बयानों की संख्या का विश्लेषण (अमूर्त लागत उपायों के बजाय) और
• निरंतर कारकों का निर्धारण।

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

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

मैं अभ्यासकर्ताओं को बेंचमार्क चलाने से पहले एल्गोरिदम के स्थान को फ़िल्टर करने के लिए सिद्धांत का उपयोग करने की सलाह देता हूं:

if ( input size forever bounded? ) {
  benchmark available implementations, choose best
  schedule new benchmarks for when machine changes
}
else {
  benchmark implementations of all asymptotically good algorithms
  choose the best
  schedule new benchmarks for when machine changes or inputs grow significantly
}

---

1. कैश की संख्या में वृद्धि होने के बाद, निरपेक्ष और सापेक्ष प्रदर्शन में पागल परिवर्तन हो सकते हैं, जो आम तौर पर तब होता है जब इनपुट बढ़ते हैं लेकिन मशीन एक ही रहती है।
2. जैसा कि, क्षेत्र में अग्रणी शोधकर्ता इसे करने में सक्षम नहीं हैं।
3. उपकरण यहाँ खोजें । एस। जंगली एट अल द्वारा MaLiJAn का उपयोग करके इंजीनियरिंग जावा 7 के दोहरी धुरी क्विकॉर्ट में एक उदाहरण उपयोग प्रकाशित किया गया है । (2012) [ प्रीप्रिंट ]
4. एस। वाइल्ड और एम। नेबेल (2012) द्वारा जावा 7 के ड्यूल पिवट क्विकॉर्ट का औसत केस विश्लेषण - [ प्रस्तावना ]

Comments

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

— राफेल

एक बार जब आप गहरी खुदाई करते हैं तो स्पर्शोन्मुख विश्लेषण की सीमा स्पष्ट हो जाती है; क्विकॉर्ट एक प्रमुख उदाहरण है ।

— राफेल

एफडब्ल्यूआईडब्ल्यू, मैंने लांडऊ संकेतन पर अपनी राय का एक और हालिया स्नैपशॉट लिखा है ।

— राफेल

Answer 2

मैं यह मानता हूं कि यह प्रश्न एक पाठ्यक्रम को पढ़ाने से उत्पन्न होता है जिसमें एसिम्प्टोटिक विश्लेषण शामिल है। इस सामग्री को परिचयात्मक कक्षाओं में क्यों पढ़ाया जाता है, इसके कई संभावित उत्तर हैं:

• एसिम्प्टोटिक विश्लेषण एक गणितीय अमूर्तता है जो खुद विश्लेषण करने के लिए पैदावार देता है। (यकीनन) गणितज्ञों के अनुसार, हम एल्गोरिदम का विश्लेषण करने में सक्षम होना चाहते हैं, और वे केवल अपनी जटिलता को वश में करने के लिए हींग का उपयोग कर रहे हैं।

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

• स्पर्शोन्मुख विश्लेषण की कुछ तकनीकें उपयोगी हैं। मैं यहां मुख्य रूप से तथाकथित "मास्टर प्रमेय" की बात कर रहा हूं, जो कई परिस्थितियों में वास्तविकता का अच्छा वर्णन है।

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

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

Comments

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

— केव

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

— राफेल

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

— युवल फिल्मस

@YuvalFilmus मैंने अक्सर समझाया है कि मुझे विश्वास नहीं है कि CS = TCS + प्रोग्रामिंग। यदि आप एक सीएस कोर्स (एक विश्वविद्यालय में) पढ़ाते हैं और आपके अधिकांश छात्र प्रोग्रामर बनना चाहते हैं, तो कुछ टूट जाता है (इम्हो)। मेरा तर्क है कि कोई भी कंप्यूटर वैज्ञानिक एल्गोरिदम, औपचारिक भाषाओं और यहां तक ​​कि कुछ जटिलता सिद्धांत (और कई अन्य चीजें, जैसे कि कंपाइलर और सीपीयू कैसे काम करते हैं) में ठोस शिक्षा से लाभ उठा सकते हैं।

— राफेल

@Wildcard कंप्यूटर वास्तुकला, कंप्यूटर ग्राफिक्स, एआई, प्रोग्रामिंग भाषा अनुसंधान, ... - सूची अंतहीन है! टीसीएस वास्तव में एक आला है, और प्रोग्रामिंग लेकिन (अधिकांश) सीएस शोधकर्ताओं के लिए एक उपकरण है।

— राफेल

Answer 3

चलने के समय के विषम विश्लेषण का उपयोग करने के दो गंभीर कारण हैं:

• $n$

• गणितीय ट्रैक्टबिलिटी की अनुमति देने के लिए। मामले ऐसे हैं कि ऑपरेशन की गणना के लिए सटीक अभिव्यक्तियां प्राप्त करना संभव है असाधारण हैं। स्पर्शोन्मुखता का अध्ययन अधिक संभावनाएं खोलता है (जैसे कि जटिल कार्यों के स्पर्शोन्मुख सन्निकटन आसान होते हैं)।

और कई अन्य हैं (जैसे मशीन स्वतंत्रता, अर्थपूर्णता, तुलनीयता ...)।

Comments

$n$

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

— राफेल

Answer 4

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

Answer 5

क्योंकि स्पर्शोन्मुख "सरल" (ठीक है, परिमित मामलों के लिए सटीक विश्लेषण करने की तुलना में सरल है, वैसे भी)।

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

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

Comments

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

— राफेल

Answer 6

यहाँ असममित विश्लेषण द्वारा मुझे लगता है कि हम एल्गोरिथ्म के व्यवहार का मतलब है कि इनपुट का आकार अनंत तक जाता है।

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

वही सवाल वास्तविक दुनिया के किसी भी सरलीकृत मॉडल के बारे में पूछा जा सकता है। हम वास्तविक दुनिया के सरलीकृत गणितीय मॉडल का उपयोग क्यों करते हैं?

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

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

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

संक्षेप में अस्वाभाविक जटिलता सरल बुनियादी कार्यों (एल्गोरिथम पाठ्यपुस्तक में समस्याएं) के लिए एल्गोरिदम की वास्तविक जटिलता का अनुमान लगाना अपेक्षाकृत आसान है। जैसा कि हम और अधिक जटिल कार्यक्रमों का निर्माण करते हैं, प्रदर्शन की आवश्यकताएं बदल जाती हैं और अधिक जटिल हो जाती हैं और विषम विश्लेषण उतना उपयोगी नहीं हो सकता है।

---

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

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

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

$\Theta(n \lg n)$$\Theta(n^2)$$\Theta(\lg n)$$O(n)$

Comments

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

— राफेल

मुझे यह उत्तर पसंद आता है। दो नोट: 1) मैं यहां "जटिलता" के बजाय "लागत" का उपयोग करूंगा। आंशिक रूप से पालतू-पीवे कारणों के लिए, लेकिन यह भी क्योंकि कई बोधगम्य लागत उपाय हैं (जो सभी उल्लेखों को उल्लिखित करते हैं)। 2) आप एक भाषा-पॉलिश पास करना चाहते हैं। ;)

— राफेल

@ राफेल, धन्यवाद। मैं जल्द ही एक और संपादन करने की योजना बना रहा हूं। :)

— केव

Answer 7

$O(n^2)$$O(n \log n)$$O(n^2)$ क्विकॉर्ट की तुलना में इसे समाप्त करने के लिए।

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

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

Comments

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

— राफेल

@ रैपेल आपने अपने जवाब में बेंचमार्किंग को कवर किया; इसका अच्छा जवाब है। लेकिन ध्यान दें कि एनीमेशन / विज़ुअलाइज़ेशन बेंचमार्किंग से निकटता से संबंधित हो सकता है। वास्तव में इस बात की बहुत व्याख्या है कि रनटाइम्स का क्या प्रभाव होता है [अन्य उत्तरों में शामिल है] लेकिन कुछ हद तक इसकी "शोर" और स्पर्शोन्मुख जटिलता "स्मूथ / शोर बाहर औसत" है। यह देखने के लिए कि वास्तव में यह कैसे करता है एक और अभ्यास करता है।

— vzn

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

— राफेल

$n$$n$

$n$