क्या कोई समस्या है जो आकार में वृद्धि के रूप में आसान हो जाती है?


62

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


7
इस संपत्ति के साथ एक वास्तविक समस्या जो दिमाग में आती है वह है अनसाल्टेड पासवर्ड हैश क्रैकिंग जब इसे "एन एन हैश, कम से कम एक हैश क्रैक" की तरह तैयार किया जाता है। चूंकि क्रैकिंग स्पीड एन के साथ रैखिक रूप से पैमाने पर होगी, इसलिए रनिंग समय 1 / n के अनुपात में होगा - सिवाय इसके कि हम वास्तव में एक निश्चित समय नहीं दे सकते क्योंकि क्रैकिंग स्टोचस्टिक है और समय पर एक निरंतर ऊपरी बाध्य नहीं है।
आमोन

1
@amon चलने का समय तरह नहीं होता है 1/n। यह समय लगता है n पढ़ने के लिए सिर्फ n हैश आप इनपुट के रूप में दिया गया है!
डेविड रिचेर्बी

3
क्या आप निरपेक्ष या सापेक्ष अर्थों में आसान हैं? आप किन लागत उपायों की अनुमति देते हैं? क्या आपको कड़ाई से घटती लागत की आवश्यकता है, या गैर-वृद्धि (कुछ बिंदु से) पर्याप्त है?
राफेल

2
@DavidRicherby इस उदाहरण में, जब तक मैं निरपेक्ष लागत के बारे में कोई बयान नहीं देता, तब तक इनपुट को पढ़ने की लागत को अनदेखा करना वैध है। इसके बजाय, इनपुट के साथ गति रैखिक रूप से बढ़ जाती है। इसलिए, इनपुट पढ़ने की लागत पर विचार करते हुए भी n • T (1)> T (n)। इस समस्या के लिए I इनपुट को विभाजित करने के बजाय एक बार में एक बड़े इनपुट को हल करना आसान है, भले ही समस्या विभाज्य हो। मैं यह नहीं कह रहा हूं कि सभी n के लिए T (n)> T (n + 1)।
आमोन

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

जवाबों:


39

नहीं, यह संभव नहीं है: कम से कम, एक asymptotic भावना है, जहां आप समस्या को कड़ाई से आसान होता जा रहा, हमेशा के लिए रखने के लिए, के रूप में की आवश्यकता होती है में नहीं n

बता दें कि ऐसी समस्या को हल करने के लिए सबसे अच्छा संभव समय है, जहां n इनपुट का आकार है। ध्यान दें कि चल रहा समय एल्गोरिथ्म द्वारा निष्पादित निर्देशों की संख्या की गणना है, इसलिए इसे एक गैर-नकारात्मक पूर्णांक होना चाहिए। दूसरे शब्दों में, टी ( एन ) एन सभी के लिए एन । अब अगर हम एक फ़ंक्शन T : NN पर विचार करते हैं, तो हम देखते हैं कि ऐसा कोई फ़ंक्शन नहीं है जो कि सख्ती से नीरस रूप से कम हो। (जो भी T ( 0 ) है, उसे परिमित होना है, T ( 0 ) कहना है )T(n)nT(n)NnT:NNT(0) ; लेकिन उसके बाद से टी होगा- सख्ती से कम हो रही है, टी ( ) 0 और टी ( + 1 ) - 1 ।, जो असंभव है) इसी तरह के कारणों के लिए, कोई समारोह है कि asymptotically सख्ती से कम हो रही है: हम इसी तरह है कि साबित कर सकते हैं कोई प्रसारण समय समारोह है टी ( एन ) जहां वहां मौजूद एन 0 ऐसा है कि सभी के लिए n एन 0 , टी ( एन )T(0)=cTT(c)0T(c+1)1T(n)n0nn0T(n) नीरस रूप से सख्ती से कम हो रहा है (इस तरह के किसी भी कार्य को अंततः नकारात्मक बनना होगा)।

तो, इस तरह की समस्या मौजूद नहीं हो सकती है, साधारण कारण के लिए जो बार चल रही है गैर-नकारात्मक पूर्णांक होना चाहिए।


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


9
यह एक अच्छा सबूत है, लेकिन मैं आधार से असहमत हूं। कड़ाई से नीरस रूप से कम होने वाले रनटाइम के लिए पूछने के बजाय, प्रश्न को अधिक यथोचित रूप से एक फ़ंक्शन की आवश्यकता हो सकती है जहां a, b के साथ मौजूद है <b ताकि T (a)> T (b), अर्थात इसका गैर-कड़ाई से monotonically कम हो। फिर, उपयुक्त पूर्णांक कार्यों को खोजना निश्चित रूप से संभव है। लेकिन पूर्णांक क्यों? मैं इस धारणा के तहत था कि रनिंग टाइम ने एक समय निरूपित किया है, न कि एक निर्देश गणना (ट्यूरिंग मशीनों के लिए) को छोड़कर, और यह कि टी एक्सप्रेशन लॉग () या नॉन-पूर्णांक एक्सप्रैसर्स की तरह नॉन-पूर्णांक संचालन का उपयोग कर सकता है।
आमोन

2
@amon "रनिंग टाइम ने एक समय निरूपित किया, एक निर्देश गिनती नहीं" बिल्कुल नहीं। रनिंग टाइम हमेशा एक इंस्ट्रक्शन काउंट होता है। किसी और चीज के बारे में तर्क करना असंभव होगा क्योंकि यह संभवतया कई कार्यान्वयन विवरणों पर निर्भर करेगा।
डेविड रिचेर्बी

3
के रूप में अस्पष्ट सवाल यह है कि के रूप में, मैं देख नहीं है कि यह कैसे की, कहते हैं, एक लागत समारोह शामिल नहीं । अब, टी ( एन ) ~ n लेकिन टी ( एन ) एन 2 "छोटे" के लिए n , तो समस्या "आसान हो जाता है", अपेक्षाकृत बोल। (बिल्कुल लागत बढ़ती asymptotically, निश्चित रूप से)। टी(n)=n2(1+ε)-n+nटी(n)~nटी(n)n2n
राफेल

2
@ रिपेल, एक समस्या आसान नहीं है: टी ( एन ) बड़ा हो जाता है जैसे ही एन बड़ा हो जाता है, इसलिए एन मुश्किल बड़ा हो जाता है, एक बार एन काफी बड़ा हो जाता है। मैंने अपने उत्तर के पहले वाक्य में कहा था कि कोई भी समस्या हमेशा के लिए आसान नहीं रह सकती। बेशक, एक समस्या थोड़ी देर के लिए आसान हो सकता है ( टी ( एन ) के लिए कम हो रही हो सकता है n सी , कहते हैं), लेकिन लेकिन यह आसान हमेशा के लिए हो रही है नहीं रख सकते हैं। टी(n)~nटी(n)nnnटी(n)nसी
डीडब्ल्यू

1
यहां तक ​​कि पूर्णांक समय के साथ, एक यादृच्छिक एल्गोरिदम के लिए अपेक्षित समय (या वितरण का कोई अन्य उपाय) आंशिक हो सकता है, और धीरे-धीरे ऊपर से कुछ स्थिर हो सकता है। [इसका मतलब यह नहीं है कि ऐसी समस्याएं वास्तव में मौजूद हैं, केवल "ऐसा कोई कार्य मौजूद नहीं है" तर्क अपर्याप्त है।]T
बेनी चेरनियाव्स्की-पास्किन

25

यद्यपि यह आपके प्रश्न का काफी उत्तर नहीं है, बॉयर-मूर स्ट्रिंग खोज एल्गोरिदम करीब आता है। जैसा कि रॉबर्ट मूर एल्गोरिथ्म के बारे में अपने वेब पेज पर कहते हैं,

हमारे एल्गोरिथ्म में अजीबोगरीब संपत्ति है जो मोटे तौर पर बोलती है, पैटर्न जितना लंबा होता है, एल्गोरिथम उतना ही तेज होता है।

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


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

4
@Kevin बयान पता चलता है कि लंबाई के एक पैटर्न खोज लंबाई मेंnपाठ लंबाईलॉगएन केपैटर्न को खोजने की तुलना में तेज है। इस तरह के फिक्स्ड-रिलेशनशिप इनपुट्स (यानी स्ट्रिंग्स के जोड़े) को देखते हुए, मुझे लगता है कि रिक ने सवाल का उपयुक्त उत्तर दिया है (यदि शास्त्रीय, विषम अर्थ में नहीं)। nnलॉग इन करेंn
राफेल

10

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

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

           |     /
           |    /
Difficulty |   /                  ____-------
           |  /           ____----
           | /    ____----
            ---------------------------------
                       Distance

प्रतिपादन : कहते हैं कि मैं एक चेहरे का एक रेंडर और 1000 चेहरों का प्रतिपादन चाहता हूं; यह बिलबोर्ड विज्ञापन के लिए है, इसलिए दोनों अंतिम छवियों को 5000px तक 10000px होना चाहिए। एक चेहरे को वास्तविक रूप से प्रस्तुत करना कठिन होगा - कई हजार पिक्सेल के रिज़ॉल्यूशन के दौरान आपको वास्तव में शक्तिशाली मशीनों का उपयोग करना होगा - लेकिन 1000 चेहरों की भीड़ के लिए प्रत्येक चेहरे को केवल दस पिक्सेल की आवश्यकता होती है, और आसानी से क्लोन किया जा सकता है! मैं शायद अपने लैपटॉप पर 1000 चेहरों को प्रस्तुत कर सकता था, लेकिन एक यथार्थवादी चेहरे को 10000px प्रदान करने में बहुत लंबा समय और शक्तिशाली मशीनें लगेंगी। ASCII का कठिनाई बनाम वस्तुओं का ग्राफ, दिखा रहा है कि एक सेट आकार की छवि के लिए n वस्तुओं को प्रदान करने की कठिनाई कितनी जल्दी बंद हो जाती है लेकिन फिर वापस आती है:

           | -    
           |- -                     _________
Difficulty |   --      ______-------            
           |     ------      
           |       
            ---------------------------------
                        Objects

हार्डवेयर नियंत्रण : हार्डवेयर के साथ कई चीजें बहुत आसान हो जाती हैं। "मूव मोटर एक्स 1 डिग्री" कठिन और / या असंभव है, और आपको उन सभी प्रकार की चीजों से निपटना होगा जो आपको "मूव मोटर एक्स 322 डिग्री" के लिए नहीं करना होगा।

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


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

रेंडरिंग उदाहरण एक ही समस्या के उदाहरण नहीं लगते हैं: पहला वाला एकल छवि प्रदान कर रहा है; दूसरा व्यक्ति कई छोटी छवियों का प्रतिपादन कर रहा है और फिर उन छवियों की कई प्रतियों को किसी क्षेत्र में चिपका रहा है।
डेविड रिचेर्बी

मुझे लगता है कि मापदंडों को यात्रा करने के लिए 2 शहरों का नाम होगा और उन्हें एनकोड करने के लिए वर्णों की संख्या होगी।
एमोरी

3

मामले हैं। वे ऐसे मामले हैं जहां सफलता मानदंड एक एकल उत्तर खोजने की कोशिश करने के बजाय डेटा का एक कार्य है। उदाहरण के लिए, सांख्यिकीय प्रक्रियाएँ जिनके परिणाम आत्मविश्वास के अंतराल से संपन्न होते हैं वे आसान हो सकते हैं।

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


2

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

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

उदाहरण: लंदन और पेरिस के बीच कार में सबसे लंबा रास्ता क्या दो बार एक फ्रांसीसी और एक ब्रिटिश शहर जाने और दूसरे देश का दौरा करने से बचना है? विचार करें, आपको एशफोर्ड से पहले बर्मिंघम जाना है, वर्साय से पहले ऑरलियन्स, लिमोगे से पहले ला रोशेल, आदि ...

यह स्पष्ट है कि लंबी प्रविष्टियों के साथ यह समस्या कम लोगों के साथ आसान होगी।

उपयोग का उदाहरण: मशीन द्वारा प्रबंधित एक playgame की कल्पना करें, और कंप्यूटर के IA को यह निर्धारित करना होगा कि क्या उसे और अधिक संकेत खोजने के लिए नाटक में अधिक अन्वेषण करना है या नहीं, अगर अब कटौती करने का समय है, तो यह मानने का सबसे अच्छा निर्णय क्या है ।


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

@ डेविड, आपकी प्रतिक्रिया पूरी तरह से गलत है: 1. प्रविष्टि कोई ग्राफ़ नहीं है: बड़ा ग्राफ़ एक PARAMETER है। तो हैमिल्टनियन समस्या एक स्थिरांक (बहुत बड़ी, लेकिन एक स्थिर) में बदल जाती है। 2. प्रविष्टि समस्या का समाधान है, इसलिए: यदि अधिक से अधिक, आप संकेत के एक संयोजन विस्फोट की पेशकश कर रहे हैं। एक संकेत का एक प्रवेश एक सहायता देता है, दो संकेत डबल, तीन संकेत 4 जुड़वा के करीब होंगे ..., क्योंकि आप संभावित समाधानों को समाप्त कर रहे हैं। तो, यह एक हैमिल्टन नहीं था, यह एक अजीब ग्राफ से एक समाधान है और समस्या समाधान के कुछ हिस्सों के साथ क्या करना है।
जुआन मैनुअल दातो

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

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

nलॉग इन करेंn

1

एक प्रोग्राम पर विचार करें जो इनपुट के रूप में लेता है जिसे आप पासवर्ड के बारे में जानते हैं और फिर इसे क्रैक करने का प्रयास करते हैं। मुझे लगता है कि यह वही करता है जो आप चाहते हैं। उदाहरण के लिए:

  • कोई इनपुट नहीं-> जानवर बल सभी प्रतीकों और किसी भी लम्बाई के एक शब्द पर दरार
  • पासवर्ड की लंबाई -> जानवर उस लंबाई के एक शब्द में सभी प्रतीकों को बल देता है
  • निहित प्रतीक -> प्रतीकों की सूची को जांचने के लिए सिकोड़ें
  • ...
  • कई घटनाओं और लंबाई सहित प्रतीक -> केवल क्रमपरिवर्तन की गणना करें
  • सही क्रम में सभी प्रतीकों -> मूल रूप से खुद को हल किया

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

तो यह सब नीचे आता है कि आप कितना अमूर्त अनुमति देते हैं।


2

0

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

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

जैसा कि आप कल्पना कर सकते हैं, कम मात्रा के साथ, चीजों को ठीक से ठीक करने के लिए शोर बहुत महत्वपूर्ण है। यदि आपके पास Cheddar के 5 उदाहरण हैं, Brie के 1, Bri के 1, और Chedar के 1, तो मैं कैसे बताऊँ कि कौन सा सही है और कौन सा टाइपो है? अधिक मात्रा के साथ, टाइपो बहुत कम रखने के लिए करते हैं, लेकिन दुर्लभ मूल्यों को कुछ महत्वपूर्ण वृद्धि मिलती है, जिससे वे शोर से बच जाते हैं (अनुभव द्वारा समर्थित)। इस मामले में, मैं उदाहरण के लिए 50000 चेडर, 3000 ब्री, 5 ब्री, 15 चेडर की कल्पना कर सकता हूं।

तो हां, कुछ समस्याएं खुद को हल कर लेती हैं, जब आपके पास पर्याप्त डेटा होता है।


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

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

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

2
"अधिक प्रभावी हो जाता है"! = "आसान हो जाता है"।
डेविड रिचेर्बी

-1

एनपी-पूर्ण समस्या 3-सैट पर विचार करें। यदि आप प्रपत्र x_i = true / false के इनपुट प्रदान करके समस्या को बढ़ाते रहते हैं, तो आप या तो व्यक्तिगत विवादों को दो-चर खंडों में परिवर्तित कर देते हैं, जिससे 2-SAT समस्या का निर्माण होता है, जो निश्चित रूप से P है, या बस समाप्त हो रहा है। एक सही / गलत जवाब।

उस मामले के लिए जहाँ x_i = true / false निविष्टियाँ उपलब्ध हैं (एक ही इनपुट बहुत बार प्रदान किया गया है, या विरोधाभासी इनपुट) आप इनपुट को आसानी से सॉर्ट कर सकते हैं और या तो निरर्थक मानों को अनदेखा कर सकते हैं, या यदि मान विरोधाभास करते हैं तो एक त्रुटि की रिपोर्ट कर सकते हैं।

किसी भी मामले में, मुझे लगता है कि यह एक 'यथार्थवादी' समस्या का प्रतिनिधित्व करता है जिसे हल करना आसान हो जाता है क्योंकि इनपुट की संख्या बढ़ती है। 'आसान' पहलू एनपी-पूर्ण समस्या को एक पी समस्या में परिवर्तित करने में है। आप अभी भी हास्यास्पद इनपुट प्रदान करके सिस्टम को गेम कर सकते हैं जैसे कि समस्या को मजबूर करने के लिए सिर्फ सॉर्टिंग को अधिक समय लगेगा।

अब, वास्तव में एक अच्छा परिदृश्य होगा यदि हम टी (0) को स्वीकार करने के लिए तैयार हैं (ऊपर दिए गए उत्तर में डीडब्ल्यू के अंकन का उपयोग करना) अनंत हो सकता है। उदाहरण के लिए, T (0) ट्यूरिंग की हॉल्टिंग समस्या को हल करने के बराबर हो सकता है। यदि हम एक समस्या को इस तरह विकसित कर सकते हैं कि अधिक इनपुट जोड़ने से यह एक हल करने योग्य समस्या में परिवर्तित हो जाए, तो हम सोने पर चोट कर सकते हैं। ध्यान दें कि यह एक हल करने योग्य समस्या में asymptotically रूप में परिवर्तित करने के लिए पर्याप्त नहीं है - क्योंकि यह समस्या को मजबूर करने के लिए उतना ही बुरा है जितना कि क्रूर।


1
ये विशेष इनपुट आसान हो जाते हैं। हालाँकि, जब आप सभी संभावित इनपुट पर विचार करते हैं तो 3SAT सामान्य रूप से काफी कठिन हो जाता है क्योंकि आप अधिक क्लॉज़ जोड़ते हैं: हार्ड इनपुट इन "हंट" क्लॉज़ के बिना होते हैं। यदि आप सामान्य जानकारी को रोक रहे हैं, तो आपको यह बताने की आवश्यकता है कि आप कौन से इनपुट की अनुमति दे रहे हैं।
डेविड रिचेर्बी

पहले बंद: हम इस बात पर सहमत हैं कि अधिक इनपुट जोड़ने से रनिंग टाइम बढ़ सकता है। मैं अनिवार्य रूप से ऊपर एक ही बात कहता हूं। दूसरा, मैं स्पष्ट रूप से कहता हूं कि हम एक मौजूदा 3-सैट ले रहे हैं और फॉर्म के केवल इनपुट जोड़ रहे हैं x_i = true / false। मुझे लगता है कि यह पर्याप्त स्पष्ट है और मुझे कोई और स्पष्टीकरण देने की आवश्यकता नहीं है। मुझे लगता है कि आपने जो लिखा है, उसकी सबसे गलत व्याख्या करने के लिए आप परेशानी उठा रहे हैं। कृपया अपने आप को परेशान न करें।
v vv cvvcv

1
नहीं, सचमुच में। आप किस कम्प्यूटेशनल समस्या को हल कर रहे हैं? एक कम्प्यूटेशनल समस्या स्ट्रिंग्स के एक सेट की सदस्यता तय कर रही है (कोडिंग के बारे में झुंझलाहट से बचने के लिए सूत्रों का एक सेट कहते हैं)। फ़ार्मुलों का सेट क्या है जिसके लिए आप यह दावा कर रहे हैं कि सेट में एक लंबा फॉर्मूला है या नहीं, यह तय करने की तुलना में आसान है कि सेट में एक छोटा फॉर्मूला है? जैसे ही आप इसे सटीक बनाने की कोशिश करते हैं, मुझे पूरा यकीन है कि आपका दावा टूट जाएगा।
डेविड रिचेर्बी

क्या आप 'मेरे दावे' की अपनी समझ को स्पष्ट कर सकते हैं? जैसे ही आप इसे सटीक बनाने की कोशिश करते हैं, मुझे पूरा यकीन है कि आप इंटरनेट बैंडविड्थ को बर्बाद करना बंद कर देंगे।
v vv cvvcv

मैं एक कंप्यूटर वैज्ञानिक हूं, दिमाग-पाठक नहीं। अपने दावे को सटीक बनाना आपका काम है, मेरा नहीं।
डेविड रिचेर्बी

-1

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


n
टीपी


n

3) आउटपुट: आउटपुट
कर्मचारियों द्वारा उठाए जाने वाले कार्यों के बीच का मार्ग है। प्रत्येक पथ इसे लेने वाले कर्मचारियों की संख्या के साथ जुड़ा हुआ है। उदाहरण के लिए:

n1
n2
n3
n4
n5

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

          ए
      ईसा पूर्व
    डे

nn1n2n20

के लिये n=n=1

n


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

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

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

मैं सहमत हूँ। ऐसा लगता है कि हम सभी इसके बारे में काफी आलोचनात्मक थे, इसके विपरीत कि मूल प्रश्न हमें क्या लुभाता है! लेकिन उम्मीद है कि आपको 'इनपुट के रूप में एक संसाधन' का मेरा विचार मिलेगा: काम कितना भी बड़ा क्यों न हो, लोग उतना ही बेहतर होंगे। फिर भी एक अस्वाभाविक अर्थ में आप निश्चित रूप से सही हैं, मुझे इसे गैर-नकारात्मक पूर्णांकों पर दोष देना चाहिए।
येमेलिटक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.