《对弈程序基本技术》专题

　

置换表

　

Bruce Moreland / 文

　

一个多功能的数据结构

　

　　国际象棋的搜索树可以用图来表示，而置换结点可以引向以前搜索过的子树上。置换表可以用来检测这种情况，从而避免重复劳动。如果“1. e4 d6 2. d4”以后的局面已经搜索过了，那就没有必要再搜索“1. d4 d6 2. e4”以后的局面了。

　　这个原因可能鼓舞着早期的电脑国际象棋程序的设计师们，而现在事实上这还是置换表的次要用途。在某些局面，例如在没有通路兵的王兵残局中，检查到的置换的数量是惊人的，以至于搜索可以在短达时间内达到很深的深度。

　　省去重复的工作，这是置换表的一大特色，但是在一般的中局局面里，置换表的另一个作用更为重要。每个散列项里都有局面中最好的着法，我在“迭代加深”这一章里解释过，首先搜索好的着法可以大幅度提高搜索效率。因此如果你在散列项里找到最好的着法，那么你首先搜索这个着法，这样会改进你的着法顺序，减少分枝因子，从而在短的时间内搜索得更深。

　

实现

　

　　主置换表是一个散列数组，每个散列项看上去像这样：

　

#define hashfEXACT 0

#define hashfALPHA 1

#define hashfBETA 2

typedef struct tagHASHE {

　U64 key;

　int depth;

　int flags;

　int value;

　MOVE best;

} HASHE;

　

　　这个散列数组是以“Zobrist键值”为指标的。你求得局面的键值，除以散列表的项数得到余数，这个散列项就代表该局面。由于很多局面都有可能跟散列表中同一项作用，因此散列项需要包含一个校验值，它可以用来确认该项就是你要找的。通常校验值是一个64位的数，也就是上面那个例子的第一个域。

　　你从搜索中得到结果后，要保存到散列表中。如果你打算用散列表来避免重复工作，那么重要的是记住搜索有多深。如果你在一个结点上搜索了3层，后来又打算做10层搜索，你就不能认为散列项里的信息是准确的。因此子树的搜索深度也要记录。

　　在Alpha-Beta搜索中，你很少能得到搜索结点的准确值。Alpha和Beta的存在有助你裁剪掉没有用的子树，但是用Alpha-Beta有个小的缺点，你通常不会知道一个结点到底有多坏或者有多好，你只是知道它足够坏或足够好，从而不需要浪费更多的时间。

　　当然，这就引发了一个问题，散列项里到底要保存什么值，并且当你要获取它时怎样来做。答案是储存一个值，另加一个标志来说明这个值是什么含义。在我上面的例子中，比方说你在评价域中保存了16，并且在标志域保存了“hashfEXACT”，这就意味着该结点的评价是准确值16；如果你在标志域中保存了“hashfALPHA”，那么结点的值最多是16；如果保存了“hashfBETA”，这个值就至少是16。

　　当你在搜索中遇到特定情况时，很容易决定评价和标志应该保存哪些内容。然而避免错误是非常重要的，散列表是非常容易犯错误的，而且一旦犯下错误就很难捕捉出来。

　　我的散列项的最后一个域，保存着上次搜索到这个局面时的最佳着法。有时我没有得到最佳着法，比如任何低出边界的情况(返回一个小于或等于Alpha的值)，而其他情况必定有最佳着法，比如高出边界的情况(返回一个大于或等于Beta的值)。【译注：只有叶子结点才没有最佳着法，即便是Alpha结点，所有的着法都是差的，也应该从中找一个最好的着法，它对更深一层的搜索会带来很大的好处。】

　　如果找到最佳着法，那么它应该首先被搜索。

　　下面是示范程序，是根据Alpha-Beta函数修改的，改动的地方用醒目的字标出：

　

int AlphaBeta(int depth, int alpha, int beta) {

　int hashf = hashfALPHA;

　if ((val = ProbeHash(depth, alpha, beta)) != valUNKNOWN) {

　　// 【valUNKNOWN必须小于-INFINITY或大于INFINITY，否则会跟评价值混淆。】

　　return val;

　}

　if (depth == 0) {

　　val = Evaluate();

　　RecordHash(depth, val, hashfEXACT);

　　return val;

　}

　GenerateLegalMoves();

　while (MovesLeft()) {

　　MakeNextMove();

　　val = -AlphaBeta(depth - 1, -beta, -alpha);

　　UnmakeMove();

　　if (val >= beta) {

　　　RecordHash(depth, beta, hashfBETA);

　　　return beta;

　　}

　　if (val > alpha) {

　　　hashf = hashfEXACT;

　　　alpha = val;

　　}

　}

　RecordHash(depth, alpha, hashf);

　return alpha;

}

　

　　以下就是两个新的函数的代码：

　

int ProbeHash(int depth, int alpha, int beta) {

　HASHE *phashe = &hash_table[ZobristKey() % TableSize()];

　if (phashe->key == ZobristKey()) {

　　if (phashe->depth >= depth) {

　　　if (phashe->flags == hashfEXACT) {

　　　　return phashe->val;

　　　}

　　　if ((phashe->flags == hashfALPHA) && (phashe->val <= alpha)) {

　　　　return alpha;

　　　}

　　　if ((phashe->flags == hashfBETA) && (phashe->val >= beta)) {

　　　　return beta;

　　　}

　　}

　　RememberBestMove();

　}

　return valUNKNOWN;

}

　

void RecordHash(int depth, int val, int hashf) {

　HASHE *phashe = &hash_table[ZobristKey() % TableSize()];

　phashe->key = ZobristKey();

　phashe->best = BestMove();

　phashe->val = val;

　phashe->hashf = hashf;

　phashe->depth = depth;

}

　

　　你所看到的代码，并不像航天科学一样准确，而是很可能有错误的，而且细节上的问题我还没有讨论。如果你的程序中有错误，或许就是很严重的错误。

　　【以上代码有个速度上的瓶颈，即“ZobristKey() % TableSize()”这个表达式。由于“电脑一做除法就成了傻瓜”，所以“TableSize”最好是一个2ⁿ的常量，只有当除数是2ⁿ时除法才可以由右移指令取代。最好的方法是设一个“TableSizeMask”的变量：

　

int TableSizeMask = TableSize() - 1;

HASHE *phashe = &hash_table[ZobristKey() & TableSizeMask];

　

　　而这里“TableSize()”也必须是2ⁿ。正是这个道理，在很多可以设定置换表大小的国际象棋程序中，允许的设定值总是呈倍数增长的，要么是3M、6M、12M、24M等等(如果每个散列项有12字节)，要么是4M、8M、16M、32M等等(如果每个散列项有16字节)。】

　

替换策略

　

　　最主要的细节就包括，什么时候该覆盖散列项。在上面的例子中，我用了“始终替换”的策略，即简单地覆盖已经存在的值。这或许不是最好的策略，事实上已经有大量的工作试图找出哪个策略是最好的。

　　另一个策略是“同样深度或更深时替换”。除非新局面的深度大于或等于散列表中已经有的值，否则已经存在的结点将被保留。

　　还有很多试验的余地。1994年我在Usenet(新闻组网络系统)的新闻组rec.games.chess(如今是rec.games.chess.computer)上问了这个问题，得到了Ken Thompson的答复。

　 　他的回答是使用两个散列表。一个使用“始终替换”策略，另一个使用“同样深度或更深时替换”。当你做试探时，两个散列表都去试探，如果其中一个可以产生 截断，那就可以了。如果两者都不能产生截断，那么你可能至少得到一个最佳着法，实际上更多的可能是得到两个不同的着法，两者都应该首先(或第二个)尝试。

　　记录的时候，你只要简单地根据替换策略来执行。

　　如果你使用“同样深度或更深时替换”的策略，那么你的散列表可能最终会被过期的但很深的结点所占满。解决方案就是每次你走棋时都清除散列表，或者在散列项中加入“顺序”这个域，从而使这个策略变成变成“同样深度，或更深，或原来是旧的搜索，才替换”。

　　我在我的程序Ferret中使用了Thompson的策略，并且运行得很好。另一个程序Gerbil也使用这个策略，你可以去看它的源代码。

　　【根据译者研究的结果，只用“深度优先覆盖”策略(即“同样深度或更深时替换”)，效果会比“始终替换”好得多，而代码则并不复杂，只有醒目的部分是新增的：

　

void RecordHash(int depth, int val, int hashf) {

　HASHE *phashe = &hash_table[ZobristKey() & (TableSize() - 1)];

　if (phashe->hashf != hashfEMPTY && phashe->depth > depth) {

　　return;

　}

　phashe->key = ZobristKey();

　phashe->best = BestMove();

　phashe->val = val;

　phashe->hashf = hashf;

　phashe->depth = depth;

}

　

　　如果使用这个代码，那么每走一步以前都必须把散列表中所有的标志项置为“hashfEMPTY”。】

　

不稳定性的问题

　

　　当你用置换表时，如果你允许搜索过程根据散列项来截断，那就会产生另一个问题，你的搜索会受“不稳定性”的捆扰。

　　不稳定性至少是由以下因素引起的：

　　1. 你可能在做6层的搜索，但是如果你在散列项中得到10层搜索的结果，就可能根据这个值来截断。在后来的搜索中，这个散列项被覆盖了，因此你在这个结点上得到了两个不同的值。

　　2. Zobrist键值无法记录到达结点的线路，这个结点上不是每条线路都有相同结果的。如果某条线路遇到重复局面，那么散列项的值就会跟路线有关。因为重复局面会导致和局的分值，或者至少不一样的分值。

　　就我所知，还没有什么办法能处理这些问题。

　　【另外，如果搜索过程中找到杀棋，那么评价值会接近“INFINITY”或“-INFINITY”，此时记录散列表时不能简单地记录这些评价值，在后面介绍的“胜利局面”的处理中，会谈到这个问题。】

　

　　原文：http://www.seanet.com/~brucemo/topics/hashing.htm

　　译者：黄晨 ()

　　类型：全译加译注

发表于 @ 2008年06月01日 20:07:00|评论(loading...)|收藏