Но возможно, и вероятно, что этот узел был посещен снова в процессе поиска через другой возможный путь. Если g из этого нового пути меньше чем g из предыдущего сохраненного пути, то мы заменяем старое значение g на новое значение g (строка 27). В строке 26 мы устанавливаем переменную родителя m на узел, из которого мы пришли. Свойство родителя мы используем в конце поиска для конструирования конечного пути. Мы можем двигаться от узла цели назад к начальной позиции, следуя свойствам родителей. Далее, мы пересчитываем f и затем пересортируем массив открытый. Мы пересортируем открытый массив потому, что мы просто обновляем один из узлов наименьшим значением f, так что этот узел может теперь получить приоритет над другим.
Я должен быть с вами честен – я не вполне уверен, что строки 30 и 31 необходимы! Это было в псевдокоде, на котором я изучал алгоритм A*, и я включил этот фрагмент в мою реализацию на ActionScript. Но эта часть алгоритма ни разу не посещалась ни в одном из примеров поиска, которые я сконструировал (я поместил оператор трассировки в эту часть кода, с тем чтобы получить информацию, если этот фрагмент кода сработает.) В процессе многих и многих испытаний я никогда не наблюдал этого. Алгоритм, написанный в ActionScript, работает точно так, как должен, и всегда возвращает путь с наименьшим счетом. Однако, я сохранил эту часть алгоритма, даже при том, что она кажется ненужной, просто на всякий случай, если я однажды пойму, зачем она могла бы понадобиться. Если вы знаток в алгоритме A*, то дайте мне знать ваши мысли по этому вопросу.
После того, как все соседи n посещены, мы переходим к строке 32. В этой строке мы кладем n в замкнутый массив, потому что он был полностью раскрыт. Затем мы проверяем время, чтобы удостовериться, что мы ищем не слишком долго. Если мы искали слишком долго, то мы устанавливаем признакПоиска в false. В противном случае, мы перемещаемся на следующий узел в ветви (строка 11). Если признакПоиска равен false, мы остановим поиск и создадим путь
Русская версия