Шахматы: Извлечение основного варианта из таблицы транспонирования

Ранее у меня была проблема, связанная с тем, что мой основной вариант был усечен альфа-бета-поиском. Действительно, похоже, это общая проблема. От авторов Crafty:

Другим решением с еще худшими свойствами является извлечение полного PV из таблицы транспонирования и отказ от полного использования треугольного массива. Если таблица транспонирования достаточно велика, чтобы вообще ничего не перезаписывалось, это почти сработает. Но есть скрытый «подводный камень». После поиска PV вы продолжаете поиск в других частях дерева, и вы часто будете снова сталкиваться с некоторыми из тех же позиций, но черновик хеш-функции не будет достаточно глубоким, чтобы можно было использовать запись. Вы продолжаете поиск и теперь должны перезаписать эту запись (этого требует точное совпадение подписи хэша), и теперь вы оставляете «след» транспонирования к другой конечной точке, которая не соответствует исходной оценке. Или любая из записей trans/ref между корнем и фактической конечной точкой PV полностью перезаписывается другой позицией, и теперь у вас нет возможности выполнить поиск в таблице транспонирования, чтобы найти фактическую конечную точку, которую вы хотите отобразить. Некоторые используют этот подход для создания PV, и жалобы, как правило, часты и громки, потому что оценка в паре с несвязанным PV не очень полезна ни для отладки, ни для анализа ваших собственных игр.

Это имеет большой смысл.

Учтите, что основным вариантом является ABCDEF, но AB возвращает доску в исходное положение. Затем альтернативная строка, рассмотренная позже, может быть CDEFGH, что приводит к другой оценке, чем предыдущий поиск только CDEF. Таким образом, запись в таблице транспонирования для состояния доски после AB перезаписывается, потенциально с узлом, который будет отрезан альфа-бета (!!), а PV ABCDEF уничтожается навсегда.

Есть ли способ обойти эту проблему, или мне нужно использовать внешнюю структуру данных для сохранения PV?

В частности, что не так с заменой тогда и только тогда, когда новая запись более глубокая и точная? Похоже, это не работает, но я не уверен, почему.


person dylhunn    schedule 13.06.2016    source источник
comment
Выкладываю обновление для читателей. Я, кажется, сохранил принципиальную вариацию с комбинацией двух изменений: 1) Никогда не заменяйте точную запись в таблице транспонирования записью отсечки. 2) Всегда заменяйте неточную запись на точную, иначе мы не сможем добавить более поверхностное окончание основного варианта. 3) В противном случае используйте глубину. 4) Когда альфа-бета-поиск не отключается, он всегда должен добавлять к таблице лучший локально ход. (Даже если ход хуже, чем альфа.) Я не уверен на 100%, что это работает во всех случаях, но мои результаты кажутся намного лучше.   -  person dylhunn    schedule 13.06.2016
comment
Вы можете посмотреть на github.com/official-stockfish/ Stockfish/blob/master/src/tt.h   -  person Nihar Karve    schedule 06.02.2020