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

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

Решение конечно-же простое... Кроме оценки возращается достоверный интервал оценки - каким бы он был если бы правило 50 ходов не сработало-бы.

 

Не то написал - я написал метод решения обратной проблемы...

 

Новый реквизит в Хеше hash50Moves, относится к оценке.
При извлечении оценки из Хеша -

// ходов по правилу 50 сделано на текущий момент + значение из Хеша
if (current50Moves+hash50moves)>=100 then
Begin

// если оценка в хеше меньше нуля, и тип оценки "<=" либо "="
if (Score<0)and(ScoreT<=0) then
Begin // поменяем извлеченную из хеша оценку на "<= 0"
Score:=0;
ScoreT:=-1;
End;

// если оценка в хеше больше нуля, и тип оценки ">=" либо "="
if (Score>0)and(ScoreT>=0) then
Begin // поменяем извлеченную из хеша оценку на ">= 0"
Score:=0;
ScoreT:=1;
End;

После этого часть захешированных оценок перестанет использоваться. (влияющих на правило 50 ходов)

 

При записи в Хеш:

Function Search(a,b:integer;Var rule50Move:integer):integer;
Var rule50;
Begin
rule50Move:=0;
kolMoves:=GenMoves();
For i:=1 to kolMoves do
MakeMove;
Score:=-Search(-B,-A,Rule50);
UnMakeMove;
if (ход не взятие и не ход пешкой) and ((score>A) or (score<0)) then
if Rule50>=rule50Move then rule50Move:=rule50+1;
if (score>=B) and (score>0) then
if (ход не взятие и не ход пешкой) then rule50move:=Rule50+1
else rule50Move:=0;


дописал условия по Score

 

rule50Move передается через параметр в вызывающую Search процедуру, и оно-же пишется в Хеш.

Я образно написал - можно добавить условий связанных со сравнением Score с нулем, чтоб глубина в хеш поменьше писалась.

 

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

 

Даже не знаю с какой стороны подойти. Первый пост, в котором корректируется оценка в хеше, понятен?

Пусть оценка в хеше опровергающая (">=" либо "<=") тогда берем срез дерева перебора так что за опровергающую сторону берутся только опровергающие ходы, а за опровергаемую все ходы. Если оценка "=" тогда берем всё поддерево.
Смотрим в этом поддереве ветвь из тихих ходов наибольшей длины и пишем её в хеш вместе с оценкой.

Это достигается вот такм кодом:

if (ход не взятие и не ход пешкой) then
if Rule50>=rule50Move then rule50Move:=rule50+1;
// если длина тихого варианта больше уже достигнутой, тогда увеличиваем её.


if (score>=B) then
if (ход не взятие и не ход пешкой) then rule50move:=Rule50+1
else rule50Move:=0;

// если узел опровергающий, то берем срез дерева только с опровергающим ходом, если при этом текущий ход не тихий, то сбрасываем счетчик тихих ходов.


Когда извлекаем оценку из хеша. Если у нас оценка опровергающая по альфе, и пр этом оценка больше нуля, то правило 50 ходов её испортить не может.
Если оценка опровергающая по альфе и меньше нуля, то её может испортить правило 50 ходов.
То есть в Хеше <=-8, но текущая длина тихого варианта + длина тихого варианта из Хеша превышает 99 полуходов. Возможно слабейшая сторона может добиться нулевой оценки. Меняем при извлечении из хеша оценку на <=0

 

Ты хочешь сделать примерно, а я пишу точно.
Ты предлагаешь использовать Depth из хеша, а я предлагаю писать в хеш реальную длину варинта без взятий и ходов пешками.

Число "тихих по правилу 50" ходов легко может быть больше чем Depth, если есть продления на шахах, на единственном ходе, либо просматриваются шахи в ФВ.

 

if (hash_entry->type == HASH_EXACT) return HASH_MISS;
В этом случае мы можем тоже использовать оценку из хеша.
Если она больше нуля, то Можно вернуть ноль, и поменять при этом тип оценки на HASH_LOW, если она больше нуля, то поменять тип оценки на HASH_HIGH, если она равна нулю, то ей можно использовать - правило 50 ходов её не исказит.

Безопасное использование оценок из хеша, при этом большинство узлов будет считать безопасными даже вблизи правила 50, при этом вычислять безопасные узлы будет без ошибок.

Мы складываем количество полуходов которые мы уже сделали по правилу 50, и количество полуходов по правилу 50 которые еще придется сделать чтоб не исказилась оценка из Хеша.

Если неиспользовать все потенциально опасные без расчета опасной глубины то полностью отключится хеширование, и соответственно резко упадет глубина перебора.

 

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

 

Ничего подобного. В ответ на плохие ходы слабейшей стороны там будет >=

Реально партии с ошибками на правиле 50 ходов встречаются достаточно часто - больше 1% партий. Причем лажаются очень многие движки.

В корне дерева, на первом ходе - примерно половина всех узлов.
На всех ответах соперника на первый (PV) ход кроме сильнейшего оценка будет ">= GlobalScore", рассмотреть все ответы на первый ход в корне мы обязаны по правилам альфа-беты.

 

Не совсем понял логику. На форуме неудобно рисовать дерево перебора, но в ответ на первый ход при максимальных отсечения по альфа-бете везде будет ">=GlobalScore" (<=-GlobalScore)
99% узлов. и 1% PV узлов.
Как они не помогают - одинаковые позиции встречаются, хеш перекрестных работает, все отcечения по ним и происходят. Если хеш перекрестных сокращает дерево в 4 раза, то по этим оценкам на первом ходе в корне мы в четыре раза дерево как раз и сократим.

А при уменьшении GlobalScore (при достижении правила 50 она приблизится к нулю) - количество отсечек по оценке ">=" не уменьшится... Но не уменьшится в том случае, если мы безопасно будем продолжать их использовать.

 

То что и остекалось.
Все не PV узлы в ответ на первый ход отсекаются именно этой оценкой.
Мы отсекаем плохие ходы соперника в ответ на первый ход в корне (по всему поддереву). а они практически все плохие.
Оценкой около нуля мы можем отсечь только плохие ходы сильнейшей стороны. А они в свою очередь появляются только при плохой сортировке. При хорошей до них дело не доходит - происходит отсечение по бете на первом-же ходе сильнейшей стороны.

 

Как помогут оценки >=GlobalScore, где GLobalScore>=0?
Так-же как и раньше.

 

Игорь!!!! Нарисуй кусок дерева начиная с лучшего хода в корне. Слабейшая сторона не может что-то не так сделать - при обдумывании за сильнейшую сторону рассматриваются ВСЕ ходы слабейшей стороны.

Сильнейшая сторона должна опровергнуть все ответы соперника. За сильнейшую сторону нужно найти только один опровергающий ход на каждый ход соперника.

То есть опровергать слабые ходы слабейшей стороны нужно всегда, и рассматривать нужно их все. Опровергать слабые ходы сильнейшей стороны нужно только если сильнейшая сторона совершила ошибку. Если сортировки верные - то первый же ход сильнейшей стороны сделает отсечку по Бете.


У нас сортировки близки к идеальным. Любой не PV узел отcекается оценкой >=GlobalScore

 

И увеличение значения оценки в Хеше по сравнению с GlobalScore только увеличит отсечения.

 

Я же написал на первый (PV) ход сильнейшей стороны мы обязаны рассмотреть все ответы соперника.
То есть дерево -
3. Qe5, допустим 3...Be7 сильнейший.
Но мы должны за слабейшую сторону рассмотреть не только ход Be7, но и все остальные ходы. И во всех поддеревьях в ответ на ходы кроме Be7 мы должны найти только один опровергающий ход сильнейшей стороны, и рассмотреть все ходы слабейшей стороны.
И любой узел этих поддеревьев отсекается как раз оценкой >=GlobalScore