सही सही उत्तरों को साबित करने के लिए कई या कठिन के साथ परीक्षण (निर्धारक) एल्गोरिदम


11

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

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

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

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

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

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

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


3
यदि भाषा इसे अनुमति देती है तो आप इसे परीक्षण करने के बजाय शुद्धता साबित कर सकते हैं
मिनीबेल

बहुत पाठ है, लेकिन कोई सवाल नहीं। तो, वास्तव में आप क्या पूछ रहे हैं?
B:08ови।

@ B @овиЈ "मुझे सही आउटपुट को सत्यापित करने के लिए कई और / या कठिन एल्गोरिदम के कार्यान्वयन का परीक्षण कैसे करना चाहिए?" मुझे यकीन नहीं है कि मुझे इतना स्पष्ट कैसे करना है, क्षमा करें। मैं अनुदान देता हूँ कि इसे आपके दृष्टिकोण के आधार पर थोड़ा व्यापक माना जा सकता है, लेकिन मुझे नहीं लगता कि यह अपरिभाषित है।
लीनियरजेट्रोपे

मुझे अभी भी समझ नहीं आया। आपका एल्गोरिथ्म यादृच्छिकता पर निर्भर नहीं करता है, और फिर भी यह अभी भी विभिन्न आउटपुट पैदा कर सकता है। इसका कोई मतलब नहीं है। प्रत्येक एल्गोरिदम, सेट इनपुट के लिए, एक ही आउटपुट होना चाहिए। और वह वही है जो यूनिट परीक्षणों में किया जाता है और परीक्षण किया जाता है। यहां तक ​​कि आपके द्वारा लिंक किए गए पेपर में एल्गोरिदम।
B28овиЈ

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

जवाबों:


5

मुझे यकीन नहीं है कि आप सही संपत्ति का परीक्षण करने की कोशिश कर रहे हैं, और यह आपकी अस्पष्टता का कारण बनता है।

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

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

उदाहरण के लिए, एक भोली परीक्षा सेटअप होगा:

  1. लालची एल्गोरिथ्म के साथ परीक्षण ग्राफ में Va और Vb के बीच सभी संभावित रास्तों की गणना करें।
  2. इनमें से प्रत्येक पथ के लिए लागत फ़ंक्शन (उदाहरण के लिए, लंबाई यदि आपके सभी किनारे का वजन 1 के बराबर है) की गणना करें।
  3. परीक्षण के तहत एल्गोरिथ्म लागू करें।
  4. अपनी इकाई के परीक्षण में जोर दें कि परीक्षण किया गया एल्गोरिथ्म लागत मूल्य लालची समाधान के न्यूनतम के बराबर है।

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


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

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

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

0

मुझे लगता है कि आपके प्रश्न का सीधा उत्तर बेहतर परीक्षा मामलों को चुनना है। मुझे आश्चर्य है कि आपके द्वारा उपयोग किए जा रहे परीक्षण मामलों के बारे में। आपके द्वारा उपयोग किए जाने वाले ग्राफ़ CANNED ग्राफ़ हो सकते हैं जहाँ अपेक्षित प्रतिक्रिया निर्धारित करना मानव के लिए अपेक्षाकृत आसान है। "किनारे" वाले मामलों का पता लगाने की कोशिश करें जिन्हें आप सुनिश्चित करना चाहते हैं कि आपके एल्गोरिथ्म हैंडल और प्रत्येक विशेष रूप से किनारे के मामलों के लिए एक कैन्ड ग्राफ बनाएं जो कि मानव के लिए गणना करना आसान है। उदाहरण के लिए, Djikstra एल्गोरिथ्म मामले में, आप संभवतः कुछ 5x5 या 7x7 ग्राफ़ बना सकते हैं जो आपके सभी किनारे मामलों को कवर करते हैं, भले ही आपका वास्तविक सिस्टम 500x500 हो।

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

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