c++ - 转位表导致国际象棋引擎输

Question

前言:我知道这个问题对于 Stack Overflow 之类的人来说可能有点太宽泛了。虽然，我尝试添加尽可能多的信息。

我正在从头开始用 C++ 编写一个国际象棋引擎，大部分已经完成(除了它的求值函数较弱)。但奇怪的是，每次启用换位表时引擎都会丢失，这是一个非常明显的错误(放弃一个皇后，或者有时一个皇后和另一个棋子)。当转置表探测被禁用时，该引擎轻松战胜了 Nero 和 TSCP。

我使用一个非常简单的换位表实现和一个始终替换的方案，取自 Bruce Morland 的网站 here .

这是探测实现:

bool probe_table(TranspositionTable& t_table, unsigned int ply,
uint64 hash_key, unsigned int depth, unsigned int& pv_move, int& score,
int alpha, int beta)
{
    unsigned int index = hash_key % t_table.num_entries;

    assert(index < t_table.num_entries);

    if(t_table.t_entry[index].hash_key == hash_key)
    {
        pv_move = t_table.t_entry[index].move;

        if(t_table.t_entry[index].depth >= depth)
        {
            score = t_table.t_entry[index].score;

            if(score > IS_MATE) score -= ply;
            else if(score < -IS_MATE) score += ply;

            switch(t_table.t_entry[index].flag)
            {
                case TFALPHA:
                {
                    if(score <= alpha)
                    {
                        score = alpha;
                        return 1;
                    }
                }
                case TFBETA:
                {
                    if(score >= beta)
                    {
                        score = beta;
                        return 1;
                    }
                }
                case TFEXACT:
                {
                    return 1;
                }
                default: assert(false); // At least one flag must be set.
            }
        }
    }

    return 0;
}

在 alpha-beta 搜索期间，将探测表格(条目也会正确存储，具体取决于截止值等):

if(probe_table(board.t_table, board.ply, board.hash_key, depth, pv_move,
    score, alpha, beta))
{
    return score;
}

编辑:为了完整起见，这里有一段在搜索中存储代码的重要部分:

if(score > alpha) // Alpha cutoff.
{
    if(score >= beta) // Beta cutoff.
    {
        ...

        store_entry(board.t_table, board.ply, board.hash_key, best_move,
                    beta, depth, TFBETA);

        return beta;
    }

    alpha = score;

    ...
    }
}

...

assert(alpha >= old_alpha);

if(alpha != old_alpha)
{
    store_entry(board.t_table, board.ply, board.hash_key, best_move,
        best_score, depth, TFEXACT);
}
else
{
    store_entry(board.t_table, board.ply, board.hash_key, best_move,
        alpha, depth, TFALPHA);
}

我已经考虑并探索了引擎所有其他部分的故障，但都没有发生。完全禁用探测(但仍然使用表来存储 PV 线)，效果很好。

我还考虑了我幼稚的思考是否会影响事情。为了思考，只要有思考 Action 可用，我只需将 bestmove xxxx ponder xxxx 打印到 UCI。如果启用思考，GUI 让引擎思考(这只是一个常规搜索，但稍后将通过换位表使用)。

为了测试，我完全禁用了思考，但没有显示出任何改进。在获得了一段时间的胜利分数后，引擎简单地放弃了它的女王。我相信发生这种情况的原因可能是表中的某些错误条目，或者可能是我无法理解的其他某种不稳定因素。

这就是我需要以前遇到过这个问题的人为我指明大致方向的地方。

编辑:正如grek40所问，这是一个刚刚发生的例子(引擎是白色的，白色的可以移动):

引擎又一次，基于愚蠢的 Action 输掉了比赛。请注意，引擎到达了这样一个错误的位置，可能是因为换位表本身。

分析这个位置在比赛中填写的换位表:

info score cp -425 depth 1 nodes 1 time 0 pv e1d1
info score cp -425 depth 2 nodes 2 time 0 pv e1d1
info score cp -425 depth 3 nodes 3 time 0 pv e1d1
info score cp -425 depth 4 nodes 4 time 0 pv e1d1
info score cp -425 depth 5 nodes 5 time 0 pv e1d1
info score cp -425 depth 6 nodes 6 time 0 pv e1d1
info score cp -425 depth 7 nodes 7 time 0 pv e1d1
info score cp -425 depth 8 nodes 8 time 0 pv e1d1
info score cp -425 depth 9 nodes 9 time 0 pv e1d1
info score cp -425 depth 10 nodes 10 time 0 pv e1d1
info score cp -440 depth 11 nodes 10285162 time 3673 pv f5f8 e7f8 b2b3 b7b5 e1c1 d6d5 a3a4
info score cp -440 depth 12 nodes 29407669 time 10845 pv f5f8 e7f8 e1f1 f8e7 f1f5 d6d5
bestmove f5f8 ponder e7f8

再次分析没有换位表(实际上，有换位表，但已清除):

info score cp -415 depth 1 nodes 82 time 0 pv f5f8
info score cp -415 depth 2 nodes 200 time 0 pv f5f8 e7f8
info score cp -405 depth 3 nodes 900 time 0 pv f5f8 e7f8 b2b3
info score cp -425 depth 4 nodes 2936 time 1 pv f5f8 e7f8 b2b3 f8e7
info score cp -415 depth 5 nodes 10988 time 4 pv f5f8 e7f8 b2b3 b7b5 e1d1
info score cp -425 depth 6 nodes 65686 time 25 pv f5f8 e7f8 e1f1 d7e7 f1d1 b7b5
info score cp -420 depth 7 nodes 194124 time 76 pv f5f8 e7f8 b2b3 b7b5 e1f1 f8e7 f1f7
info score cp -425 depth 8 nodes 357753 time 141 pv f5f8 e7f8 b2b3 b7b5 e1f1 f8e7 f1f5 d7c7
info score cp -425 depth 9 nodes 779686 time 292 pv f5f8 e7f8 e1f1 f8e7 f1f5 h4h8
info score cp -425 depth 10 nodes 1484178 time 560 pv f5f8 e7f8 e1f1 f8e7 f1f5 h4h8
info score cp -435 depth 11 nodes 29481132 time 11117 pv f5f8 d6d5 e1e5
info score cp -435 depth 12 nodes 106448053 time 41083 pv f5f8 e7f8
bestmove f5f8 ponder e7f8

值得注意的是，在深度 10 上，换位表搜索的分数是准确的。

编辑:这个位置是赛后分析的。在游戏过程中，引擎没有足够的时间完成更高深度的搜索，导致它播放 e1d1，这很荒谬。

为什么会发生这种情况？引擎从深度 1 开始找到更好的移动，但从换位表中找到了不同的移动。我也想知道为什么换位表搜索没有pv线。

我最好的猜测 是来自 Bruce Morland 网站的搜索不稳定性引用:Zobrist key 不考虑到达节点所采用的路径。并非每条路径都是相同的。如果在树中的某个其他点遇到，散列元素中的分数可能基于将包含重复的路径。重复可能会导致平局得分，或者至少会导致不同的得分。

编辑:我尝试在没有 TFEXACT 值时禁用存储到表中。也就是说，我停止了存储和检索 TFALPHA/TFBETA 值，并且它工作得很好。有人知道为什么吗？

Answer 1

我注意到您正在设置您的(传递引用)pv_move before 检查您的深度标准是否满足。这意味着 probe_table 可能正在更改 pv_move 并且仍然返回 0(未命中)(并且不设置 得分)。这看起来很糟糕？