एक एल्गोरिथ्म के Landau संकेतन (बिग हे या थीटा संकेतन) को खोजने का कार्यक्रम?

11

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

मैंने कुछ समय कॉडिलिटी (कोडिंग / एल्गो अभ्यास) पर बिताया, और उन्होंने देखा कि वे आपके प्रस्तुत समाधान (समय और स्मृति उपयोग दोनों) के लिए आपको लांडऊ संकेतन देंगे।

मैं सोच रहा था कि वे ऐसा कैसे करेंगे ... आप इसे कैसे करेंगे?

क्या लेक्सिकल एनालिसिस या कोड के पार्सिंग के अलावा कोई और तरीका है?

यह सवाल मुख्य रूप से PHP और जावास्क्रिप्ट की चिंता करता है, लेकिन मैं किसी भी भाषा और सिद्धांत के लिए खोला गया हूं।

— जूलियन एल
स्रोत

4

इस उत्तर को SO से जांचें । ऐसा लगता है कि आप क्या देख रहे हैं।

— डेको

2

यदि आप एक प्रोग्राम बना सकते हैं जो प्रत्येक एल्गोरिथ्म के लिए इस समस्या को हल करता है, तो आप "उस आदमी के रूप में प्रसिद्ध हो जाएंगे जिसने ट्यूरिंग को बाधित किया था"।

— user281377

1

ऐसे साक्ष्यों के लिए, जो चल रहे समय को तय करना सामान्य रूप से असंभव है, यहां और यहां देखें - वास्तव में आपके द्वारा पूछे गए जवाबों से भी अधिक उत्तर वहां साबित होते हैं।

— एलेक्स दस ब्रिंक

13

मैं सोच रहा था कि वे ऐसा कैसे करेंगे ... आप इसे कैसे करेंगे?

मुझे लगता है कि वे वास्तव में बिग ओ उपायों का अनुमान लगा रहे हैं ... विभिन्न समस्याओं के आकार के लिए कार्यक्रम चलाकर, समय और स्थान के उपयोग को मापते हैं, और परिणामों को मोड़ते हैं।

इस दृष्टिकोण के साथ समस्या यह है कि यह गलत हो सकता है यदि लागत फ़ंक्शन आकार में बदल जाता है क्योंकि एन बड़ा हो जाता है; उदा 1000 N + N^1.5।

क्या लेक्सिकल एनालिसिस या कोड के पार्सिंग के अलावा कोई और तरीका है?

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

— स्टीफन सी
स्रोत

6

"पहले से अज्ञात एल्गोरिथ्म के लिए स्वचालित रूप से करना कठिन है" - अधिक सटीक: यह हॉल्टिंग समस्या को हल करने के बराबर है।

— जोर्ग डब्ल्यू मित्तग सेप

एर्म ... बिल्कुल नहीं। हाल्टिंग प्रॉब्लम को हल करना पहले के सभी अज्ञात एल्गोरिदम के लिए सक्षम होने के बराबर होगा ।

— स्टीफन सी।

2

हाँ क्षमा करें। एक एल्गोरिथ्म के लिए ऐसा करना समाप्ति को साबित करने के बराबर (या इसके बजाय) है।

— जॉर्ग डब्ल्यू मित्तग सेप

1

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

— स्टीफन सी।

3

वे कोड का विश्लेषण किए बिना नहीं कर सकते।

जटिलता के कृत्रिम "मुद्रास्फीति / अपस्फीति" के साथ नीचे दिए गए उदाहरणों से साबित होता है कि बस प्रोग्राम रनटाइम को मापना मज़बूती से बिग-ओ के लिए पर्याप्त नहीं है

void lets_trick_runtime(int n) {
   if (n == 10 || n == 25 || n == 118) {
      // unfair speed-up
      do_precalculated_solution_in_constant_time(n);
      return;
   }
   if (n == 11 || n == 26 || n == 119) {
      // unfair slow-down
      do_some_fake_processing_in_n_cube_time(n);
      return;
   }
   // fair solution
   do_general_solution_in_quadratic_time(n);
}

उपरोक्त के लिए रनटाइम अनुमान नकली अनुमान देने के लिए सुगम होगा - मूल्यों के लिए निरंतर समय nजहां मूल्यों के लिए पूर्व-गणना समाधान और क्यूबिक समय है, जहां unfair slow-down"निष्पक्ष" द्विघात समय के बजाय - में किक करता है।

— कुटकी
स्रोत

हालांकि, अगर वे "अनुचित" मामलों की जांच करने के लिए होते हैं, तो वे अभी भी मान सकते हैं कि सबसे खराब स्थिति वास्तव में बिग-ओ जटिलता का अनुमान लगाती है।

— यम मार्कोविच

1

मुझे लगता है कि यह संभव नहीं है।

यदि आप एक निश्चित संख्या में विभिन्न इनपुट आकारों के साथ कुछ परीक्षण चलाते हैं, तो आप आसानी से एक बहुपद की गणना कर सकते हैं, जो आपके द्वारा चलाए जा रहे रनटाइम्स को अनुमानित करेगा। तो आप हर संभव कार्यक्रम के लिए एक बहुपद के साथ अंत करते हैं, जिसका अर्थ होगा P = NP(हाँ!))।

यदि आप इसे प्रतीकात्मक हेरफेर के साथ करने की कोशिश करते हैं, तो आप इसे समाप्त करते हैं halting problem। चूँकि आप तय नहीं कर सकते कि आपका कार्यक्रम कभी रुक जाएगा, आप तय नहीं कर सकते कि इसमें कितनी जटिलता होगी।

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

— SpaceTrucker
स्रोत

1

+1, हालांकि मुझे लगता है कि रुकने की समस्या को दुर्लभता माना जा सकता है।

— यम मारकोविक

0

मैं यह कैसे करूंगा? जिस तरह से मैं लगभग किसी भी समस्या को हल करता हूं, मैं बैठकर हल नहीं करना चाहता । मैं अनुकरण करता हूं।

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

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

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

— Fomite
स्रोत

0

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

— veryfoolish
स्रोत