Algorithm 国际象棋：从转置表中提取主要变量

早些时候，我遇到了一个问题，涉及到我的主要变体被alpha-beta搜索截断。事实上，这似乎是一个共同的问题。来自《诡计多端》的作者：

另一种性能更差的解决方案是提取完整的PV 从换位表中，避免使用三角形数组 完全是。如果换位表足够大 没有任何内容被覆盖，这几乎可以正常工作。但是有 一个隐藏的“抓住你了”。搜索PV后，您将继续搜索 树的其他部分，你会经常遇到一些 同样的位置，但散列草稿不够深入 以允许使用该条目。您继续搜索，现在必须 覆盖该项（精确的哈希签名匹配需要此项）并 现在，您将换位“轨迹”保留到另一个端点，一个端点 与原始分数不符。或任何一个trans/ref 根和实际PV端点之间的条目被 一个完全不同的位置，你现在无法搜索 换位表以查找要显示的实际端点。 有几家公司使用这种方法生产PV，投诉如下： 通常频繁且响亮，因为评估与 无关PV对于调试或分析都不是很有用 你自己的游戏

这很有道理

考虑主要的变化是ABCDEF，但AB将板返回到其原始位置。然后，稍后检查的另一条线可能是CDEFGH，这会导致与之前仅搜索CDEF不同的评估结果。因此，AB之后的线路板状态的换位表条目被覆盖，可能有一个节点将被alpha beta（！！）切断，ABCDEF的PV将永远被破坏

有没有办法解决这个问题，或者我必须使用外部数据结构来保存PV

---

具体来说，如果且仅当新条目更深入、更准确时才替换有什么错？这似乎不起作用，但我不确定原因。

我发布了一个更新，以方便读者。我似乎通过两个变化的组合保留了主要的变化：1）永远不要用截断项替换换位表中的精确项。2） 总是用精确的条目替换不精确的条目——否则，我们可能无法添加主变体的“较浅”结尾。3） 否则，使用深度。4） 当alpha-beta搜索没有中断时，它应该始终将本地最佳移动添加到表中。（即使移动比alpha差。）我不是100%相信这在所有情况下都有效，但我的结果似乎要好得多。你可能想看看