क्या सभी प्रोग्रामिंग समस्याएं एल्गोरिदम समस्याएं हैं? [बन्द है]


13

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

इसलिए मेरा सवाल है, जैसा कि शीर्षक में कहा गया है। क्या इस एल्गोरिदमिक फैशन में सोचकर हर सॉल्व करने योग्य प्रोग्रामिंग समस्या है। कोई बात नहीं, जो भाषा, क्षेत्र, आदि? यदि हाँ, तो तर्क दीजिए, अन्यथा, तर्क दीजिए!

मैंने GUI, AI, ग्राफ़िक्स, आदि के साथ कई जटिल कार्यक्रमों को लागू नहीं किया है ... लेकिन क्या इस प्रकार की समस्याएं अच्छे एल्गोरिदम को सोचने का विषय भी हैं?


6
एक प्रोग्रामर, imho के लिए सबसे आम समस्या यह है: "ओह, यह वही था जो आपका मतलब था? अब मुझे समझ में आया। यह वह नहीं है जिसे मैंने लागू किया है, क्षमा करें"। क्या वह प्रोग्रामिंग समस्या है?
केप्पला

1
यह प्रश्न बहुत समान है।
back2dos

आपको क्लाइंट के साथ एक रिपोर्ट करने की जरूरत है, उनकी आवश्यकताओं का वर्णन करें और उसके आधार पर आपको सॉफ्टवेयर को डिजाइन, टेस्ट, इंप्लीमेंट, रिफलेक्टर, ऑप्टिमाइज़ और मेंटेन करना होगा। आपको सॉफ्टवेयर का परीक्षण, विकास, तैनाती, चलाने और मापने के लिए वातावरण की आवश्यकता है। इस प्रणाली में एक व्यक्तिगत एल्गोरिथ्म सिर्फ एक कार्यान्वयन विवरण है।
inf3rno

@ कीप्पला (प्लस वन) ओपी, यह एक आवश्यकता की समस्या है, सभी सॉफ़्टवेयर संकटों का मूल कारण
मावग का कहना है कि मोनिका

जवाबों:


29

यह निर्भर करता है कि आप "प्रोग्रामिंग समस्या" को कैसे परिभाषित करते हैं।

वास्तविक दुनिया की परियोजनाओं में, उत्तर निश्चित रूप से एक स्पष्ट नहीं है। अधिकांश समस्याएं तकनीकी समस्याएं भी नहीं हैं, लेकिन संचार समस्याएं, आवश्यकताएं जो अस्पष्ट हैं, आदि।

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

कुछ क्षेत्र हैं, जहाँ समस्याएँ उस क्षेत्र की प्रकृति से बहुत अधिक एल्गोरिदम हैं। उदाहरण के लिए, AI एक प्रमुख विषय है, जहां एल्गोरिदम कोर पर हैं। ग्राफिक्स एल्गोरिदम गहन हो सकता है, लेकिन यह इस बात पर निर्भर करता है कि "ग्राफिक्स प्रोग्रामिंग" के साथ वास्तव में क्या है।

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

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


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

यह अपने सबसे सख्त अर्थों में सच है, लेकिन मैं, एक के लिए, i++हमारे नए अधिपति के रूप में स्वीकार नहीं करता .. erm .. एल्गोरिथ्म।
फ्रैंक

लेकिन क्या होगा अगर हमें इसके अलावा के बारे में पता नहीं है। फिर इसके अलावा एल्गोरिदम के हमारे अध्ययन में एक महान नवाचार की शुरूआत होगी! और इसलिए जब तक हम अधिक से अधिक जटिल एल्गोरिदम का सामना करते हैं।
CMCDragonkai

8

प्रोग्रामिंग समस्या से आपका क्या अभिप्राय है?

विकिपीडिया के अनुसार:

कंप्यूटर प्रोग्रामिंग (अक्सर प्रोग्रामिंग या कोडिंग के लिए छोटा) कंप्यूटर प्रोग्राम के स्रोत कोड को डिजाइन करने, लिखने, परीक्षण, डिबगिंग और बनाए रखने की प्रक्रिया है।

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

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

इसी तरह, कई डेवलपर के कार्य एल्गोरिदम से असंबंधित हैं। उदाहरण: अंतर्राष्ट्रीयकरण। उसी तरह, बहुत सारे एप्लिकेशन (उदाहरण के लिए CRUD) अपने सोर्स कोड में एल्गोरिदम का बहुत अधिक उपयोग नहीं करते हैं (फ्रेमवर्क के अंतर्निहित कोड के बारे में बात नहीं कर रहे हैं)।

अब, यदि आप मान रहे हैं कि "प्रोग्रामिंग समस्या" में, "प्रोग्रामिंग" कोड के माध्यम से एल्गोरिदम के अनुवाद का पर्याय है, तो हाँ, तार्किक रूप से कोई भी समस्या एल्गोरिथम समस्या होगी: A × n = B × nयदि A = B


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

आपका कार्य, जैसा कि वर्णित है, कार्यक्रम के व्यवहार में परिवर्तन नहीं करता है। संभवतः यह कुछ अन्य परिवर्तनों के लिए प्रारंभिक कार्य है, जिसमें एल्गोरिदम शामिल हो सकते हैं या नहीं भी हो सकते हैं। मुझे नहीं लगता कि कहीं भी किसी को भी पूरे दिन काम करने वाले कोड को रिफलेक्टर करने के लिए भुगतान किया जाता है।
MarkJ

6

मुझे लगता है कि जवाब सशक्त रूप से नहीं है । एल्गोरिदम बस एक बहुत बड़े कौशल सेट में ब्लॉक का निर्माण कर रहे हैं।

मैंने सीएस में अपनी डिग्री हासिल की, एआई में विशेषज्ञता हासिल की

वहाँ मूलभूत समस्या, कम से कम जैसा कि मैंने इसे देखा था, जानकारी के लिए अच्छा प्रतिनिधित्व खोजना था । इन अभ्यावेदन को लोगों के सिर में मौजूद ज्ञान संरचनाओं के लिए अच्छे मेल होने की कोशिश करनी चाहिए, और उन पर किए जाने वाले जोड़तोड़ और परिवर्तन की सुविधा प्रदान करनी चाहिए।

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

एल्गोरिदम भी महत्वपूर्ण हैं, लेकिन वे केवल कहानी का हिस्सा हैं।


5

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

दूसरे शब्दों में, अगर आपके कोड पूरी तरह से मनुष्यों के लिए समझ से बाहर हैं, तो कंप्यूटर परवाह नहीं करता है। वे इसे ठीक वैसे ही चलाएंगे। यह चुनौती पर्याप्त रूप से कोड स्पष्ट करने में है कि कोई भी गला खटखटाने की तरह खड़ा होगा।

दिलचस्प बात यह है कि एल्गोरिदम के बारे में मैंने कॉलेज में जो तकनीकी चीजें सीखीं, उन्हें लंबे समय से मैंने अपने दम पर सीखा है। इस बिंदु पर अगर मैं अपनी नौकरी में मेरी मदद करने के लिए एक 3 जी कॉलेज की डिग्री प्राप्त करना चाहता था, तो यह अंग्रेजी रचना में होगी।


2

अधिकांश प्रोग्रामिंग समस्याएं वास्तव में सिस्टम एडमिनिस्ट्रेशन समस्याएं हैं।

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

एल्गोरिदम सही होना आमतौर पर समस्या का केवल एक छोटा सा हिस्सा है। बाकी समस्या वास्तविक दुनिया में वास्तविक समस्याओं को हल करने के लिए कार्यक्रम डाल रही है।


"एल्गोरिदम सही होना आमतौर पर समस्या का केवल एक छोटा सा हिस्सा है" kaggle.com पर समस्याएं। [TM] उस विवरण को फिट नहीं करते हैं।
गंडालफ

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

2

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

ऊपर से कुछ उदाहरण लेना

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

प्रोग्रामिंग और यहां तक ​​कि डिज़ाइन के संदर्भ में, ऐसे पैटर्न / नियम पता होंगे जो प्रभावी GUI डिज़ाइन का नेतृत्व करते हैं जो उपयोगकर्ता के अनुकूल और कुशल हैं। इन नियमों को एक एल्गोरिथ्म तक घटाया जा सकता है, यदि इसके बाद उपयोगकर्ता के अनुकूल जीयूआई बनाने में मदद करनी चाहिए। वास्तव में GUI पर नियंत्रण रखने के वास्तविक चरणों को एक एल्गोरिथ्म में भी कम किया जा सकता है

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

लेकिन जिस तरह से आप यूनिट परीक्षणों को जोड़ते हैं वह एक एल्गोरिथ्म द्वारा वर्णित किया जा सकता है जैसे कि

  1. नए यूनिट टेस्ट को पहचानें
  2. यूनिट टेस्ट लिखें
  3. पूंजीकरण सामान्यीकरण एल्गोरिथम लागू करें
  4. टिप्पणियाँ एल्गोरिथ्म लागू करें

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

अधिकांश Yes उत्तरों के साथ समस्या यह है कि लोग निर्देश के एक सेट के बजाय QuickSort, Bubble सॉर्ट के संदर्भ में एल्गोरिदम के बारे में सोच रहे हैं जो स्पष्ट रूप से परिभाषित तर्क / नियमों के एक सेट के लिए एक समस्या का एक अस्पष्ट वर्णन कम कर देता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.