xqbase / eleeye Goto Github PK

建议用Rust语言重写一遍。Rust不只是安全，运行速度还有概率快过C语言，C语言的运行速度不一定能追上Rust。

仔细的阅读了你们的代码，关于重复局面裁剪，你们采用了判断长捉和长将的方法来裁剪。
的确，如果不裁剪，程序会出现死循环。
我认为裁剪的一个思路就是：如果该点 在博弈树中该点到根的路径上 出现过，则这个点就没有意义再搜索下去。换句话说，如果对手下了一步棋给我，这个局面 在到根路径上 出现过，则对手下这步棋一定是没意义的。
那么，我有个疑问。我看了你们的代码，你们是在递归搜索函数一开始的时候就进行重复裁剪的。可是为什么不选择在生成着法的时候就进行裁剪呢。虽然后者会有其他的代价，但总的来说，还是后者的“搜索剪枝能力”更强。

我把你们search.cpp中的空着裁剪打了注释，同样让引擎搜10个局面，每个都只搜1秒。
我发现有空着裁剪比没有空着裁剪要多搜2层！
有空着裁剪时，1s可平均搜9层，没有只能搜7层

之后，我在自己的引擎上尝试了下空着裁剪，搜索层次大大提升，而且没有搜挂

我百思不得其解，为什么？你们能为我解答一下吗？多谢
空着裁剪的一个条件是要当前局面的分数不小于200分，但这种局面很多吗？为什么会裁剪得那么厉害？

看了2天**象棋官方规则，读了你们的代码

我发现，eleeye并没有对禁止着法进行分析，是吗，而是采用读入界面给的banmoves来排除禁止着法。然而，现在的象棋巫师可以分析禁止着法吗？我记得象棋百科网上说是没有这个功能的。

我看了genmoves.cpp中 int PositionStruct::ChasedBy(int mv) const 函数，关于捉的检测。这个函数只对上一步走了 车、马、炮 后进行捉的检测，而根据官方规定，捉的检测当然不止此。

我也注意到eleeye是有对长将和长捉进行判定的，一旦在搜索时出现长将或长捉，会判定为无害裁剪而剪枝掉。

我想问的是，官方定义的很复杂很复杂的 禁止着法 的那一套规则，不把其加入引擎中，不会有大问题吗？

谢谢。

search.h，search.cpp中，为什么要将 Search 与 Search2 分开？我看了你们代码后，认为二者没有冲突的地方，可以合并为一体。

如题

如题，谢谢。

目前的编码是GBK，在Linux下默认字符集是UTF-8，输出的中文都是乱码（我就试了一下联赛引擎）。用iconv转换成UTF-8之后重新编译即可正常输出中文。

建议通过类似的脚本批量转换成UTF-8字符集，以处理多平台的中文乱码问题

for file in *.cpp
do
    iconv -f GBK -t UTF-8 -o "${file}.new" "${file}" && mv -f "${file}.new" "${file}"
done

// 2. MVV(LVA)启发，可能要循环若干次；
case PHASE_GOODCAP:
if (nMoveIndex < nMoveNum && mvs[nMoveIndex].wvl > 1) {
// 注意：MVV(LVA)值不超过1，则说明吃子不是直接能获得优势的，这些着法将留在以后搜索
nMoveIndex ++;
__ASSERT_PIECE(pos.ucpcSquares[DST(mvs[nMoveIndex - 1].wmv)]);
return mvs[nMoveIndex - 1].wmv;
}

我认为应该改成这样：

// 2. MVV(LVA)启发，可能要循环若干次；
case PHASE_GOODCAP:
if (nMoveIndex < nMoveNum && mvs[nMoveIndex].wvl > 1) {
// 注意：MVV(LVA)值不超过1，则说明吃子不是直接能获得优势的，这些着法将留在以后搜索
nMoveIndex ++;
__ASSERT_PIECE(pos.ucpcSquares[DST(mvs[nMoveIndex - 1].wmv)]);
return mvs[nMoveIndex - 1].wmv;
}
else {
nPhase = PHASE_KILLER1;
}

否则 NextFull函数永远不会跑到 case PHASE_KILLER1 部分，也自然不会跑到后面的 case PHASE_KILLER2，case PHASE_GEN_NONCAP，case PHASE_REST等部分。。