डी *, डी * -लाइट, या इस श्रेणी में वृद्धिशील एल्गोरिदम में से किसी का उपयोग करते समय एक बड़ा चेतावनी है (और यह ध्यान देने योग्य है कि यह चेतावनी साहित्य में उल्लिखित है)। इस प्रकार के एल्गोरिदम एक उलट खोज का उपयोग करते हैं। यही है, वे लक्ष्य नोड से बाहर की ओर लागत की गणना करते हैं, जैसे एक लहर बाहर की ओर फैलती है। जब किनारों की लागत बदल जाती है (जैसे आप अपने उदाहरण में एक दीवार जोड़ते हैं या हटाते हैं) तो वे सभी अलग-अलग कुशल रणनीतियाँ हैं जो केवल खोजे गए (उर्फ 'विज़िट') नोड्स के सबसेट को अपडेट करने के लिए होती हैं जो परिवर्तनों से प्रभावित होती हैं।
बड़ी चेतावनी यह है कि लक्ष्य स्थान के संबंध में इन परिवर्तनों का स्थान एल्गोरिदम की दक्षता में भारी अंतर करता है। मैं विभिन्न कागजात और मेरी थीसिस है कि यह पूरी तरह संभव है में पता चला है इन वृद्धिशील एल्गोरिदम में से किसी की सबसे ज्यादा मामले प्रदर्शन होने के लिए भी बदतर दूर सभी जानकारी फेंकने और कुछ सादे पुराने ए * जैसी गैर-वृद्धिशील साथ नए सिरे से शुरू करने की तुलना में।
जब परिवर्तित लागत जानकारी विस्तृत खोज सामने ('विज़िट किए गए' क्षेत्र) की परिधि के करीब होती है, तो कुछ रास्तों को बदलना पड़ता है, और वृद्धिशील अद्यतन तेजी से होते हैं। एक प्रासंगिक उदाहरण एक मोबाइल रोबोट है जिसके शरीर में सेंसर लगे होते हैं। सेंसर केवल दुनिया को रोबोट के पास देखते हैं, और इसलिए इस क्षेत्र में परिवर्तन होते हैं। यह क्षेत्र खोज का प्रारंभिक बिंदु है, लक्ष्य नहीं, और इसलिए सब कुछ अच्छी तरह से काम करता है और एल्गोरिदम परिवर्तनों के लिए सही करने के लिए इष्टतम पथ को अपडेट करने में बहुत कुशल हैं।
जब परिवर्तित लागत जानकारी खोज के लक्ष्य के करीब होती है (या आपका परिदृश्य लक्ष्य परिवर्तन स्थानों को देखता है, केवल शुरुआत नहीं), तो ये एल्गोरिदम भयावह मंदी का शिकार होते हैं। इस परिदृश्य में, लगभग सभी सहेजी गई जानकारी को अद्यतन करने की आवश्यकता है, क्योंकि परिवर्तित क्षेत्र लक्ष्य के इतना करीब है कि लगभग सभी पूर्व-परिकलित पथ परिवर्तनों से गुजरते हैं और उनका पुनर्मूल्यांकन किया जाना चाहिए। वृद्धिशील अद्यतन करने के लिए अतिरिक्त जानकारी और गणनाओं को संग्रहीत करने के ओवरहेड के कारण, इस पैमाने पर एक पुनर्मूल्यांकन एक नई शुरुआत की तुलना में धीमा है।
चूंकि आपका उदाहरण परिदृश्य उपयोगकर्ता को अपनी इच्छा के अनुसार किसी भी दीवार को स्थानांतरित करने के लिए प्रकट होता है, इसलिए यदि आप D *, D * -Lite, LPA *, आदि का उपयोग करते हैं, तो आपको यह समस्या होगी। आपके एल्गोरिथ्म का समय-प्रदर्शन परिवर्तनशील होगा, उपयोगकर्ता पर निर्भर इनपुट। सामान्य तौर पर, "यह एक बुरी बात है" ...
एक उदाहरण के रूप में, सीएमयू में अलोंजो केली के समूह का एक शानदार कार्यक्रम था जिसे परसेप्टर कहा जाता था, जो वास्तविक समय में सभी साझा धारणा धारणाओं के साथ जमीनी रोबोटों को जोड़ने की कोशिश करता था। जब उन्होंने एक ग्राउंड वाहन की योजना प्रणाली को वास्तविक समय लागत अपडेट प्रदान करने के लिए एक हेलिकॉप्टर का उपयोग करने की कोशिश की, तो उन्होंने इस समस्या पर प्रहार किया क्योंकि हेलिकॉप्टर ग्राउंड व्हीकल के आगे उड़ सकता है, लागत में परिवर्तन को लक्ष्य के करीब देखते हुए, और इस तरह धीमा उनके एल्गोरिदम नीचे। क्या उन्होंने इस दिलचस्प अवलोकन पर चर्चा की? नहीं। अंत में, वे सबसे अच्छे तरीके से कामयाब रहे कि हेलीकॉप्टर को सीधे ग्राउंड व्हीकल के ऊपर से उड़ना था - जिससे यह दुनिया का सबसे महंगा सेंसर मस्तूल बन गया। निश्चित, मैं क्षुद्र हो रहा हूं। लेकिन यह एक बड़ी समस्या है कि कोई भी इस बारे में बात नहीं करना चाहता - और उन्हें,
केवल कुछ मुट्ठी भर कागज हैं जो इस पर चर्चा करते हैं, ज्यादातर मेरे द्वारा। इस प्रश्न में सूचीबद्ध मूल पत्रों के लेखकों या छात्रों द्वारा लिखे गए पत्रों में से, मैं केवल एक के बारे में सोच सकता हूं जो वास्तव में इस समस्या का उल्लेख करता है। लिकचेव और फर्ग्यूसन सुझाव देते हैं कि आवश्यक अपडेट के पैमाने का अनुमान लगाने की कोशिश करें, और संग्रहीत जानकारी को फ्लश करें यदि वृद्धिशील अपडेट को एक नई शुरुआत से अधिक समय लगने का अनुमान है। यह एक बहुत ही समझदार काम है, लेकिन अन्य भी हैं। मेरी पीएचडी कम्प्यूटेशनल समस्याओं की एक विस्तृत श्रृंखला में एक समान दृष्टिकोण को सामान्यीकृत करती है और इस प्रश्न के दायरे से परे हो रही है, हालांकि आप संदर्भों को उपयोगी पा सकते हैं क्योंकि इसमें इन एल्गोरिदमों और अधिक का गहन अवलोकन है। Http://db.acfr.usyd.edu.au/download.php/Allen2011_Thesis.pdf?id=2364 देखें ब्योरा हेतु।
