कम्प्यूटेशनल रूप से असंभव व्यावसायिक समस्या का एक उदाहरण क्या है?


17

मेरे पास सहकर्मी हैं जो वास्तविकता को स्वीकार करने से इनकार करते हैं कि ट्यूरिंग मशीन (और विस्तार से वॉन न्यूमन मशीन) अपनी स्वयं की हॉल्टिंग समस्या को हल नहीं कर सकती हैं:

आप पर्याप्त समय और धन के साथ कुछ भी कर सकते हैं।

उन्होंने यह भी तर्क देते हुए सैद्धांतिक समस्याओं को नापसंद किया:

हमारे क्षेत्र में, हम उन प्रश्नों में कभी नहीं भागेंगे। हम एप्लिकेशन डेवलपर हैं, सैद्धांतिक वैज्ञानिक नहीं।

क्या व्यावसायिक समस्या का एक अच्छा उदाहरण है जो कम्प्यूटेशनल रूप से असंभव है कि मैं उसे इस बात को समझाने में मदद कर सकूं?


11
आप उदाहरण के द्वारा प्रदर्शित नहीं कर सकते हैं कि कुछ असंभव है। आपका सहकर्मी बस यही कहेगा कि "यह काम नहीं कर रहा है क्योंकि हमने सही दृष्टिकोण का पता नहीं लगाया है"। सबसे अच्छा आप कर सकते हैं उसे एक सबूत दिखाते हैं। यदि वह इसे नहीं खरीदता है, तो वह वास्तव में मूर्ख या मूर्ख या दोनों है। यहाँ अनिर्दिष्ट समस्याओं की एक सूची दी गई है: en.wikipedia.org/wiki/List_of_undecidable_problems
थॉमस एडिंग

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

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

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

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

जवाबों:


11

तकनीकी रूप से असंभव नहीं है, लेकिन ...

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

समस्याओं के अन्य उदाहरण जो तकनीकी रूप से असंभव नहीं हैं, लेकिन तकनीकी रूप से कठिन हैं, यहां पाया जा सकता है

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

दैनिक व्यवहार में, हम अस्पष्ट तरीके से ट्यूरिंग पूर्णता के बारे में बात करते हैं, न कि कुछ गणितीय सिद्धांत का प्रदर्शन करने के लिए, लेकिन उदाहरण के लिए (उदाहरण के लिए) HTML और CSS की अपर्याप्तता को फीचर-पूर्ण कार्यक्रमों के उत्पादन के लिए एक पूर्ण वाहन के रूप में।

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


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

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

4

अन्य लोगों ने इस पर टिप्पणी की है, लेकिन मैं अपनी बात देते हुए उत्तर लिखने का प्रयास करूंगा।

मुझे रॉबर्ट हार्वे उत्तर, और उनके उत्तर की टिप्पणियाँ पसंद हैं, और मैं उन पर विस्तार करना चाहूंगा।

मुझे लगता है कि आपको इन अपरिहार्य समस्याओं (जैसे समाप्ति) को एक सांसारिक तरीके से प्रस्तुत करना होगा: उदाहरण के लिए, एक आईडीई टूल जो "जांचता है कि क्या यह फ़ंक्शन हमेशा मान देता है"।

पढ़ाने के दौरान, मेरा पसंदीदा उदाहरण रिफैक्टिंग ( कार्य समतुल्यता, एक और अनिर्दिष्ट समस्या ) था। मैंने पूछा:

यदि आपकी अच्छी रीफैक्टरिंग के बाद कोई फ़ंक्शन / प्रोग्राम ऐसा करता है तो आप कैसे जांचते हैं? निश्चित रूप से, हमारे पास इसके लिए यूनिट परीक्षण हैं, लेकिन वे सभी मामलों को कवर नहीं करते हैं। और वे लिखने के लिए उबाऊ हैं ... लेकिन हम प्रोग्रामर हैं! हमें एक प्रोग्राम लिखना चाहिए जो यह जांचता है कि क्या ये दो कार्य हमेशा एक ही परिणाम उत्पन्न कर रहे हैं! आप इसे लिखने की कोशिश क्यों नहीं करते?

या, भिन्नता के रूप में शायद आपके मामले के करीब:

हमारे पास यह विरासत कोड एक प्राचीन अस्पष्ट COBOL बोली में लिखा गया है, जिसके लिए कोई कल्पना और / या संकलक मौजूद नहीं है। हमारे पास केवल कार्यक्रम है। हमारा पूरा व्यवसाय इस पर निर्भर करता है, इसलिए हमें 100% सुनिश्चित होना चाहिए कि नया जावा कोड हर स्थिति में ठीक वैसा ही हो। प्रबंधन एक ऐसा कार्यक्रम चाहता है जो ऐसा करे, सभी संभावित मामलों की जाँच करे, और अनुमान लगाए कि यह 6 से 8 सप्ताह में किया जा सकता है। आप इसे लिखने की कोशिश क्यों नहीं करते?

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

आपको समस्या को पहचानने योग्य और स्पष्ट रूप से सरल तरीके से पेश करने का एक तरीका निकालना होगा। आपको विश्वास नहीं होगा कि कितने सीएस छात्र सीधे कम्प्यूटेशनल क्लास लेने से पहले इस तरह के कार्यक्रम को लिखने की कोशिश करेंगे ... :)


आपकी दूसरी बोली हॉल्टिंग समस्या को गलत तरीके से लागू करने का प्रयास करती है; हालाँकि, जब हम जानते हैं कि COBOL प्रोग्राम काम करता है और इसे एक परीक्षण वातावरण में निष्पादित कर सकता है (vm-clone all PROD if if be need) हॉल्टिंग समस्या को बाहर रखा गया है और हम प्रयास कर सकते हैं। शायद कार्यक्रम के बजाय हाथ से लेकिन सभी एक ही हम इसे कर सकते हैं। यदि आवश्यक हो तो हम सभी संभावित इनपुट रूपों को ट्री-बिसेक्ट कर सकते हैं। क्योंकि टारगेट प्रोग्राम रुकता है, इसलिए ट्री-बाइसक्ट करेगा।
जोशुआ

2

यह मानते हुए कि हम नैतिक प्रश्नों को एक पल के लिए अलग रख सकते हैं:

Business A ने आपको A1 और A2 में अधिकृत लोगों के अलावा उपग्रह कार्यालयों A1 और A2 के बीच संचार करने के तरीके के लिए अनुबंधित किया है।

Business B ने A1 और A2 के बीच सभी संचारों पर समझदारी से विचार करने के लिए आपको अनुबंधित किया है।

जाहिर है आप दोनों नहीं कर सकते।

गणित के काम करने के तरीके के कारण (सटीक गणित 100 वर्षों से चल रहे शोध के अधीन है), निम्नलिखित आवश्यकताओं में से एक नहीं हो सकता है:

(1): एक एन्क्रिप्शन एल्गोरिथ्म प्रदान करें जो एक हमलावर द्वारा मनमाने ढंग से उपलब्ध धनराशि के साथ नहीं तोड़ा जा सकता है।

(2): एक मनमाना एन्क्रिप्शन एल्गोरिथ्म के लिए एन्क्रिप्शन ब्रेकिंग एल्गोरिदम प्रदान करें जो उचित समय में चलता है।


1
(३): बाज़ार के बाद एक और नौकरी पाने में नाकाम रहने पर भी आप दोनों का प्रयास
रहेगा

1

मैंने हाल ही में बिजनेस प्रोसेस मॉडल और नोटेशन ( BPMN ) पर एक क्लास ली है । वहाँ यह आसानी से देखा जा सकता है कि बहुत से विभाजन, जोड़ और छोरों के साथ वर्कफ़्लोज़ जल्दी से अव्यावहारिक हो जाते हैं (हालांकि जरूरी नहीं कि असंभव हो , AFAIK) समझने और नियंत्रण करने के लिए, (जब आप XOR- विभाजन के बजाय बहुत सारे OR-विभाजन का उपयोग करते हैं)।

सॉफ़्टवेयर उद्योग के लिए, मुझे लगता है कि कोड कवरेज विश्लेषण में "समान स्थिति कवरेज" की समान समस्याओं के लिए समान है ।

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

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


0

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

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


-6

शायद इसका जवाब यह है कि आपका सहकर्मी सही है। शायद आपने ट्यूरिंग को गलत समझा है, या यह यहां कैसे लागू होता है?

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

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

आप सोच सकते हैं कि एक कार्यक्रम जैसा { while true: print "running"; print "halted"; }एक काउंटर-उदाहरण है, लेकिन ऐसा नहीं है। इस कार्यक्रम के दुष्प्रभाव हैं, जो इसे रोकने का कारण हो सकता है या नहीं। साइड इफेक्ट्स को नजरअंदाज करते हुए, एक औपचारिक प्रमाण तैयार करना संभव है कि यह कार्यक्रम रुक नहीं जाएगा। इस सवाल में हम केवल उन कार्यक्रमों से चिंतित हैं जो गैर-ठहराव के औपचारिक प्रमाण को मिटाते हैं, जहां रुकने का प्रश्न अनिर्दिष्ट है। यह ऐसा कोई कार्यक्रम नहीं है।

यह 'मजबूत' ट्यूरिंग को 'कमजोर' ट्यूरिंग से अलग करने में मदद कर सकता है। मजबूत ट्यूरिंग मशीनें वास्तव में अनंत हैं और यदि वे रुकने में विफल रहती हैं, तो वे अनंत समय तक चलेंगी। हम उन का निर्माण नहीं कर सकते।

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

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

गंभीरता से, हालांकि विवाद सीमा के बारे में है। ट्यूरिंग और एनपी पूरा हमें बताता है कि किसी भी बजट के भीतर या किसी भी समय पर कंप्यूटरों द्वारा कुछ समस्याओं को हल नहीं किया जा सकता है, चाहे वह बजट कितना भी बड़ा हो या कितना भी सामान्य क्यों न हो। उस तरह की समस्या के उदाहरण लाजिमी हैं: क्रिप्टोग्राफ़िक कुंजियाँ तोड़ना; सैकड़ों पतों पर डिलीवरी करने के लिए मार्गों का अनुकूलन; ट्रकों में पैकिंग बॉक्स; बड़े कार्यक्रमों में बग ढूंढना!

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


2
रुकने की समस्या का सार यह है कि समस्याओं के वर्ग हैं जिन्हें गणना नहीं की जा सकती है, कभी भी - अनंत समय और धन के साथ। यही बात मेरे सहकर्मी ने मानने से इंकार कर दिया।
जेसन फफन

तब हम असहमत होते हैं। मैंने अपना उत्तर संपादित कर दिया है, लेकिन अनिवार्य रूप से संदेश वही है। आपके प्रश्न के रूप में आपके पास कोई उत्तर नहीं है (या कोई भी आपको पसंद नहीं करेगा), लेकिन अंतर्निहित यह एक वास्तविक मुद्दा है और बनाया जाने वाला एक वास्तविक बिंदु है। यदि आप इस तर्क को जीतना चाहते हैं, तो आपको कुछ हद तक जमीन को स्थानांतरित करना होगा, और मैंने ऐसा करने में कुछ मदद देने की कोशिश की है। [मुझे याद दिलाएं कि इस तरह के सवालों का फिर से जवाब देने की कोशिश न करें - नकारात्मक वोट अवांछित हैं।]
david.pfx

2
@ साइमन: खुद को दोहराने के जोखिम में, ऐसे कोई कार्यक्रम नहीं हैं जो पूरा करने के लिए अनंत समय लेते हैं क्योंकि ट्यूरिंग पूर्ण कंप्यूटर नहीं हैं, बस उनके लिए परिमित परिमितियां हैं। आप यह साबित नहीं कर सकते हैं कि एक मनमाना कार्यक्रम किसी भी विधि द्वारा उस समय की किसी भी राशि में पूरा हो जाएगा जो वास्तव में कार्यक्रम को चलाने की तुलना में तेज है। व्यवहार में, 'अनंत' शब्द के साथ किसी भी वाक्य में कोई मतलब नहीं है।
david.pfx

3
while True: print "doing stuff"; print "Finished"; यह एक कार्यक्रम का एक उदाहरण है जो समाप्त होने में अनंत समय लेता है। अन्य कार्यक्रमों की एक अनंत राशि है जिसे पूरा करने के लिए अनंत समय लगता है। हम नियमित रूप से ऐसे कार्यक्रम बनाते हैं जो उद्देश्य को पूरा करने के लिए अनंत समय लेते हैं। उन्हें 'लंबी चलने वाली प्रक्रियाएं' कहा जाता है। अधिकांश गतिशील वेबसाइटें एक का उदाहरण हैं।
२१'१४ को

2
यह निश्चित रूप से है कि कंप्यूटर प्रोग्राम के सेट हैं जो प्रभावी रूप से अनंत हैं, वे कभी भी अपनी खुद की भाप के नीचे नहीं रुकेंगे (हम ब्रेक को दबाएंगे, शक्ति को बाहर निकालेंगे आदि), अगर हमने उन्हें ट्यूरिंग मशीन में प्रोग्राम किया है। बिना रुके दौड़ें। हॉल्टिंग समस्या का सार यह है कि व्यावहारिक रूप से या सैद्धांतिक रूप से सभी एल्गोरिदम पर गैर-हॉल्टिंग कार्यक्रमों को निर्धारित करने का कोई तरीका नहीं है।
एलिस्टेयर मैकेंजी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.