【发布时间】：2016-07-03 20:06:36
【问题描述】：
我正在实现一个国际象棋引擎，并且我编写了一个相当复杂的 alpha-beta 搜索例程，其中包含静止搜索和转置表。但是，我观察到一个奇怪的错误。
评估函数使用的是方格表，例如棋子：
static int ptable_pawn[64] = {
0, 0, 0, 0, 0, 0, 0, 0,
30, 35, 35, 40, 40, 35, 35, 30,
20, 25, 25, 30, 30, 25, 25, 20,
10, 20, 20, 20, 20, 20, 20, 10,
3, 0, 14, 15, 15, 14, 0, 3,
0, 5, 3, 10, 10, 3, 5, 0,
5, 5, 5, 5, 5, 5, 5, 5,
0, 0, 0, 0, 0, 0, 0, 0
};
当轮到黑方时，桌子在 x 轴上反射。具体来说，如果你很好奇，查找是这样发生的，其中 A-H 列映射到 0-7，行是从白色一侧开始的 0-7：
int ptable_index_for_white(int col, int row) {
return col+56-(row*8);
}
int ptable_index_for_black(int col, int row) {
return col+(row*8);
}
因此，在 h4（坐标 7、3）上的棋子对于白色来说价值 3 分（厘兵），而在 f6（坐标 5、5）上的棋子对于黑色来说价值 3 分。
目前整个评价函数都是片方表和材料。
在更大的搜索深度，我的引擎选择了一些真正可怕的动作。考虑这个从起始位置生成的输出：
Iterative Deepening Analysis Results (including cached analysis)
Searching at depth 1... d1 [+0.10]: 1.b1c3
(4 new nodes, 39 new qnodes, 0 qnode aborts, 0ms), 162kN/s
Searching at depth 2... d2 [+0.00]: 1.e2e4 d7d5
(34 new nodes, 78 new qnodes, 0 qnode aborts, 1ms), 135kN/s
Searching at depth 3... d3 [+0.30]: 1.d2d4 d7d5 2.c1f4
(179 new nodes, 1310 new qnodes, 0 qnode aborts, 4ms), 337kN/s
Searching at depth 4... d4 [+0.00]: 1.g1f3 b8c6 2.e2e4 d7d5
(728 new nodes, 2222 new qnodes, 0 qnode aborts, 14ms), 213kN/s
Searching at depth 5... d5 [+0.20]: 1.b1a3 g8f6 2.d2d4 h8g8 3.c1f4
(3508 new nodes, 27635 new qnodes, 0 qnode aborts, 103ms), 302kN/s
Searching at depth 6... d6 [-0.08]: 1.d2d4 a7a5 2.c1f4 b7b6 3.f4c1 c8b7
(21033 new nodes, 112915 new qnodes, 0 qnode aborts, 654ms), 205kN/s
Searching at depth 7... d7 [+0.20]: 1.b1a3 g8f6 2.a1b1 h8g8 3.d2d4 g8h8 4.c1f4
(39763 new nodes, 330837 new qnodes, 0 qnode aborts, 1438ms), 258kN/s
Searching at depth 8... d8 [-0.05]: 1.e2e4 a7a6 2.e4e5 a6a5 3.h2h4 d7d6 4.e5d6 c7d6
(251338 new nodes, 2054526 new qnodes, 0 qnode aborts, 12098ms), 191kN/s
在深度 8 处，请注意黑方以“... a7a6 ... a6a5”的移动开局，根据棋盘桌，这很可怕。此外，“h2h4”对于白人来说是一个可怕的举动。为什么我的搜索功能会选择如此奇怪的动作？值得注意的是，这只会在更深的地方开始发生（深度 3 的移动看起来很好）。
此外，搜索经常会出错！考虑以下位置：
引擎推荐了一个可怕的错误（3... f5h3），不知何故错过了明显的回复（4.g2h3）：
Searching at depth 7... d7 [+0.17]: 3...f5h3 4.e3e4 h3g4 5.f2f3 g8f6 6.e4d5 f6d5
(156240 new nodes, 3473795 new qnodes, 0 qnode aborts, 17715ms), 205kN/s
不涉及静止搜索，因为错误发生在第 1 层 (!!)。
这是我的搜索功能的代码。很抱歉它太长了：我尽我所能简化了，但我不知道哪些部分与错误无关。我认为我的算法在某种程度上是错误的。
该实现几乎完全基于维基百科的this one。 （更新：我已经大大简化了搜索，我的错误仍然存在。）
// Unified alpha-beta and quiescence search
int abq(board *b, int alpha, int beta, int ply) {
pthread_testcancel(); // To allow search worker thread termination
bool quiescence = (ply <= 0);
// Generate all possible moves for the quiscence search or normal search, and compute the
// static evaluation if applicable.
move *moves = NULL;
int num_available_moves = 0;
if (quiescence) moves = board_moves(b, &num_available_moves, true); // Generate only captures
else moves = board_moves(b, &num_available_moves, false); // Generate all moves
if (quiescence && !useqsearch) return relative_evaluation(b); // If qsearch is turned off
// Abort if the quiescence search is too deep (currently 45 plies)
if (ply < -quiesce_ply_cutoff) {
sstats.qnode_aborts++;
return relative_evaluation(b);
}
// Allow the quiescence search to generate cutoffs
if (quiescence) {
int score = relative_evaluation(b);
alpha = max(alpha, score);
if (alpha >= beta) return score;
}
// Update search stats
if (quiescence) sstats.qnodes_searched++;
else sstats.nodes_searched++;
// Search hueristic: sort exchanges using MVV-LVA
if (quiescence && mvvlva) nlopt_qsort_r(moves, num_available_moves, sizeof(move), b, &capture_move_comparator);
move best_move_yet = no_move;
int best_score_yet = NEG_INFINITY;
int num_moves_actually_examined = 0; // We might end up in checkmate
for (int i = num_available_moves - 1; i >= 0; i--) { // Iterate backwards to match MVV-LVA sort order
apply(b, moves[i]);
// never move into check
coord king_loc = b->black_to_move ? b->white_king : b->black_king; // for side that just moved
if (in_check(b, king_loc.col, king_loc.row, !(b->black_to_move))) {
unapply(b, moves[i]);
continue;
}
int score = -abq(b, -beta, -alpha, ply - 1);
num_moves_actually_examined++;
unapply(b, moves[i]);
if (score >= best_score_yet) {
best_score_yet = score;
best_move_yet = moves[i];
}
alpha = max(alpha, best_score_yet);
if (alpha >= beta) break;
}
// We have no available moves (or captures) that don't leave us in check
// This means checkmate or stalemate in normal search
// It might mean no captures are available in quiescence search
if (num_moves_actually_examined == 0) {
if (quiescence) return relative_evaluation(b); // TODO: qsearch doesn't understand stalemate or checkmate
coord king_loc = b->black_to_move ? b->black_king : b->white_king;
if (in_check(b, king_loc.col, king_loc.row, b->black_to_move)) return NEG_INFINITY; // checkmate
else return 0; // stalemate
}
// record the selected move in the transposition table
evaltype type = (quiescence) ? qexact : exact;
evaluation eval = {.best = best_move_yet, .score = best_score_yet, .type = type, .depth = ply};
tt_put(b, eval);
return best_score_yet;
}
/*
* Returns a relative evaluation of the board position from the perspective of the side about to move.
*/
int relative_evaluation(board *b) {
int evaluation = evaluate(b);
if (b->black_to_move) evaluation = -evaluation;
return evaluation;
}
我正在像这样调用搜索：
int result = abq(b, NEG_INFINITY, POS_INFINITY, ply);
编辑：即使我简化了搜索例程，该错误仍然存在。引擎只是把碎片弄错了。您可以通过在 XBoard（或任何其他与 UCI 兼容的 GUI）中加载它并在强大的引擎上运行它来轻松地看到这一点。应manlio的要求，我上传了代码：
这里是 GitHub 存储库（链接已删除；问题出在上面的 sn-p 中）。它将在 OS X 或任何 *nix 系统上使用“make”构建。
【问题讨论】：
-
stackoverflow 上有很多用户。其中有多少国际象棋引擎实现者？我不知道，但如果你没有得到这个答案，我不会感到惊讶。 :)
-
长而有趣的问题，但是我认为如果您将其发布在专门的国际象棋编程论坛上，您会得到更好的答案。其中之一是Computer Chess Club: Programming and Technical Discussions。那里有很多真正的专家。
-
如果还没有尝试过，我首先建议在没有转置表的情况下在这个位置上测试引擎（例如用
if(false)替换if (stored != NULL && stored->depth >= ply)）以确保错误不是由于 TT 代码不一致。 -
@Arnauld 谢谢，但这并没有修复错误。
-
另外，您是否确认搜索后的电路板结构与搜索前的状态完全相同？我知道这听起来像是一个相当愚蠢的检查，但是 make/unmake 例程中的一些错误可能只会在某些情况下触发（如castling或en-passant capture）并完全破坏分析。
标签： algorithm artificial-intelligence chess minimax alpha-beta-pruning