Існує велике застереження при використанні D *, D * -Lite або будь-якого з додаткових алгоритмів цієї категорії (і варто зазначити, що цей застереження рідко згадується в літературі). Ці типи алгоритмів використовують зворотний пошук. Тобто вони обчислюють витрати назовні від вузла цілі, як пульсація, яка поширюється назовні. Коли вартість ребер змінюється (наприклад, ви додаєте або видаляєте стіну у своєму прикладі), всі вони мають різні ефективні стратегії лише для оновлення підмножини досліджуваних (так званих "відвідуваних" вузлів, на які впливають зміни.
Велике застереження полягає в тому, що розташування цих змін щодо місця розташування цілі робить величезну різницю в ефективності алгоритмів. Я показав у різних працях і свою тезу, що цілком можливо, що в гіршому випадку виконання будь-якого з цих покрокових алгоритмів може бути гіршим, ніж викидати всю інформацію та починати заново з чогось неінкрементального, як звичайний старий A *.
Коли змінена інформація про вартість близька до периметра розширюваного фронту пошуку ("відвіданий" регіон), мало шляхів доводиться змінювати, і додаткові оновлення швидко проходять. Доречний приклад - мобільний робот з датчиками, прикріпленими до його тіла. Датчики бачать світ лише біля робота, а значить, зміни є і в цьому регіоні. Цей регіон є початковою точкою пошуку, а не метою, і тому все працює добре, і алгоритми дуже ефективні при оновленні оптимального шляху для виправлення змін.
Коли змінена інформація про вартість близька до мети пошуку (або ваш сценарій бачить ціль зміни локації, а не лише початок), ці алгоритми зазнають катастрофічного уповільнення. У цьому сценарії майже всю збережену інформацію потрібно оновлювати, оскільки змінена область настільки близька до мети, що майже всі попередньо обчислені шляхи проходять через зміни і повинні бути повторно оцінені. Через надмірне зберігання додаткової інформації та обчислення для поступових оновлень, повторна оцінка за цією шкалою відбувається повільніше, ніж новий початок.
Оскільки ваш приклад сценарію дозволяє користувачеві переміщати будь-яку стіну, яку він бажає, ви будете зазнавати цієї проблеми, якщо будете використовувати D *, D * -Lite, LPA * і т.д. Час роботи вашого алгоритму буде змінним, залежно від користувача вхід. Загалом, "це погано" ...
Наприклад, група Алонцо Келлі в КМУ мала фантастичну програму під назвою PerceptOR, яка намагалася поєднувати наземних роботів з повітряними роботами, які обмінювалися інформацією про сприйняття в режимі реального часу. Коли вони намагалися скористатися вертольотом, щоб забезпечити оновлення витрат у режимі реального часу на систему планування наземного транспортного засобу, вони натрапили на цю проблему, оскільки вертоліт міг літати попереду наземного транспортного засобу, побачивши зміни вартості ближче до мети, і тим самим сповільнити вниз їх алгоритми. Чи обговорювали вони це цікаве спостереження? Ні. Зрештою, найкращим, що їм вдалося, було те, щоб вертоліт летів прямо над наземним транспортним засобом - це зробило його найдорожчою щогловою щоглою в світі. Звичайно, я дріб'язковий. Але це велика проблема, про яку ніхто не хоче говорити - і вони повинні,
Є лише кілька паперів, які обговорюють це, в основному я. З робіт, написаних авторами чи студентами авторів оригінальних робіт, перелічених у цьому запитанні, я можу придумати лише одну, яка фактично згадує про цю проблему. Ліхачов і Фергюсон пропонують спробувати оцінити масштаб необхідних оновлень і промити збережену інформацію, якщо, за оцінками, додаткове оновлення триватиме довше, ніж новий початок. Це досить розумне рішення, але є й інші. Мій доктор наук узагальнює подібний підхід у широкому спектрі обчислювальних задач і виходить за рамки цього питання, однак ви можете вважати, що посилання є корисними, оскільки в ньому є ретельний огляд більшості цих алгоритмів та інше. Див. Http://db.acfr.usyd.edu.au/download.php/Allen2011_Tthes.pdf?id=2364 для деталей.