Хеширование и счетчик 50 ходов

Конечно мало - всего-лишь половина всех узлов дерева
На первый ход сильнейшей стороны в корне 50% всех узлов дерева.
В ответ - 1% PV, 99% отсекаемых оценкой >=GlobalScore.
Это в случае идеальной сортировки. Но в реальной программе сортировки близки к идеальным. А если даже и будут неидеальными - то сокращение числа отсекаемых ходов в ответ на первый ход из корня компенсируется отсечками на остальных ходах из корня дерева.

я послал в мыло рисунок по тем узлам которые отсекаются.

 

В ответ на плохие ходы слабейшей стороны (а их рассмотреть придется) опровергающими могут быть (и скорей всего будут) взятия и продвижения пешек. Оценки узлов после плохих ходов слабейшей стороны срабатывать и будут. Если хеширование отключится то быстро отсекаться эти ветви не будут. Они будут занимать подавляющий процент от всего перебора.

А если просто отключать хеш - то по какому признаку? По Depth не получится, так как могут быть продления. Отключать всегда оценки >=А при А>0 - получим ухудшение бренчинг-фактора.

 

Я не понял, как ты будешь отсекать оценки из хеша? по depth ведь не выйдет...

Когда это еще произойдет, до этого еще досчитаться надо ©

 

Но у меня будет в хеше больше позиций, и это хорошо...
А наоборот, оценки испорченные достижением правила 50 ходов (либо нулевые) ты как исключаешь? Или они пишутся в Хеш?

Я условия если оценка в A-B окне сформулировал. В примере я поставил правильные условия только если опровержение по альфе либо бете.

 

ИМХО когда в каждой записи в Хеше мы уверены что
1. Не будет ни одной неправильно взятой из хеша оценки.
2. По возможности максимально используются оценки из Хеша.
Это хорошо, и это не изврат.
Для этого достаточно возвращать два параметра и аккуратно прописать их использование в нескольких местах. (это для правила 50 ходов)

Без этого обходятся авторы движков с открытыми исходниками, но это не значит что без этого обходятся все

 

Чтоб не хешировать оценки искаженные нулевой оценкой от правила 50-ти - нужно добавить 5 строк в одно место.

 

Эх, не утерпел

С правилом 50 ходов есть 2 принципиально разные ситуации:
а) выигрыш об'ективно есть, но 50 ходов не хватает
б) выигрыша нет.

Об "искажении оценки" можно говорить в первом случае (программа правильно считает, что есть об'ективный перевес, но не учитывает правила 50 ходов, не позволяющего перевес реализовать) приличная программа должна знать все законные исключения правила и писать письмо в ФИДЕ, если найдет новое за доской.

А в ситуация, когда происходит повтор позиции, т.е. об'ективно перевеса нет, и правило лишь обрывает бессмысленное возюкание фигур по доске, мозги нужно вправлять программе, чтобы правильно оценивала позиции якобы с перевесом. Если я правильно понимаю, программа с феном получает информацию о правиле 50 ходов. Если позиция из загашника имеет большее число ходов "до контроля", то это - серьезный повод подумать о переоценке позиции.

 

Совершенно другие две ситуации, и обе связаны с ошибками на захешированных оценках
Если бы не было Хеша, то никаких проблем с правилом 50-ти нет.

 

Мы, возможно, не можем понять друг друга.

По оригинальному описанию WildCat, я нахожусь в полной уверенности, что у него речь идет о ситуации б): программа считает, что перевес есть, тогда как реально позиция ничейна. Оценка ведь не хешируется абстрактно: она должна быть привязана позиции, а с парой оценка-позиция должно хранить и число ходов по правилу 50.

Если для текущей позиции
Мы вытаскиваем из хеша позицию с ненулевой оценкой, но меньшим числом ходов по правилу 50
То встает толстый вопрос:
А верна ли ненулевая оценка?

Вообще, мне кажется, здесь заложен лучший для традиционной программы (т.е. программы, не анализирующей позицию на какие-либо виды позиционной ничьи) способ определения позиционной ничьи - если мы стали вытаскивать позиции где число ходов меньше, то мы вертимся по кругу)

Или хеш - это что-то совсем другое в этом контексте?

 

Да, это один из двух случаев - решение этой проблемы описано на первой странице ветки...