回應1：yjr123   主題：Re:   2005/2/17 下午 03:00:32 

从国际象棋软件的发展趋势来看，残局完全靠引擎不能和人类高手对抗。

回應2：Poor   主題：Re:   2005/2/17 下午 08:18:29 

現在論壇上有殘局庫的高手Pai，也已經發展好幾年了。

回應3：yjr123   主題：Re:   2005/2/18 上午 11:17:26 

这种类型的残局库没有和对奕引擎结合，只能对特定盘面进行查询，作为字典类型查询可以，用做实战则不合适。而且体积巨大，无法上网的朋友或者网站有问题时均无法使用。
我们需要的是软件在计算过程中使用残局学习文件，如和学习文件吻合则可以给出一个精确的审局结论，可以引导软件向有利于自己的方向发展。而不是向开局库一样到了某盘面才去查询着法。

回應4：yjr123   主題：Re:   2005/2/18 上午 11:24:25 

残局学习文件应该是HASH表的扩展，作为一种审局手段，和开局库不是一种类型，这样才能和人一样，通过计算某盘面最后会导致某种例胜或例和，从而对当前盘面作出着法选择。

回應5：yjr123   主題：Re:   2005/2/18 上午 11:38:52 

pai的残局库发展了好几年，但还没有达到实用要求，实战残局几乎都用不上。
人只是掌握了少量的例胜例和，就可以在残局阶段发挥出巨大威力，为什么？
如果已经走到例胜例和局面，那一切都太晚了，就算软件会从巨大的残局库中查到正确着法，人也能正确应对，软件也不占优势。
要能引导盘面向有利于自己的方向发展，这才是关键，希望有志于棋软开发的爱好者深思。

回應6：蜂蜜   主題：Re:   2005/2/20 上午 01:05:31 

N久以來，還就係你這個~~playboy~~~深合吾滴胃口~~

~嘻嘻~~~~

你那郵箱~~根本不會收信~~~

回應7：Pai   主題：Re:   2005/2/20 下午 09:07:22 

關於這個題目我有一些看法

回應8：meifire   主題：Re:   2005/2/20 下午 10:23:23 

Pai兄,弈天刚柔相济局的征答已经结束.

回應9：Pai   主題：Re:   2005/2/20 下午 11:33:45 

是實上我當初開始寫殘局庫便是為了要和对奕引擎结合,而且效果還算不錯。我的做法是,依據盤面先查詢殘局表看是否該盤面已經被殘局庫涵蓋,若是,則視此盤面為最終盤面,而立刻中止這一支的搜尋。若否,則依據此盤面查詢一個例胜例和表,再依據結果給一個相當大的分數調整。如此便能很有效率的將局面導向有利自己的殘局。而且一旦進入殘局庫所涵蓋的盤面,程式便能近乎完美的下完殘局。

根據我實作結果,效果不錯。可惜我的程式中局不夠強大,撐到殘局的盤數不多。可是撐到殘局的棋都蠻賞心悅目的。

至於殘局庫体积巨大似乎不是個大問題。二個200G的硬碟我想能買電腦的人也該付擔得起吧!

回應10：Pai   主題：Re:   2005/2/20 下午 11:43:14 

meifire 兄,已經看到。:-)

回應11：meifire   主題：Re:   2005/2/21 上午 12:26:08 

Pai兄上次给的炮兵仕相全对士象全、马兵仕对卒士的残局不如也公开发表一下吧？

回應12：meifire   主題：Re:   2005/2/21 上午 12:36:19 

对残局的定义可能还不太统一，不过在实战中，双方各剩下两个左右的大子，还有若干兵卒，就称为实战残局了，这离目前已实现的残局库应该还有很大距离吧？

回應13：yjr123   主題：Re:   2005/2/21 下午 06:27:22 

我主要有两层意思，一是要和引擎结合，是在计算过程中利用残局库作为审局而不是对已经走成的盘面进行着法搜寻；二是要设法缩小体积，而提出的一种设想。
你这200G我不知道是什么概念，是已经完成的部分200G，还是估计完成后有200G，如果形势完全一样，只是红黑互换是否也能使用，而实际上2个200G要负担也不是买不起，但相信现在玩电脑象棋软件的人几乎没有人会配这么大的硬盘。

回應14：yjr123   主題：Re:   2005/2/21 下午 06:35:36 

对于第1层意思，举个例子，如图形势，如红方车马脱身则胜定，现在被牵则只有兑车用马胜单相，对于最初的形势，残局库中是没有的，但经过6～8层的计算，必然在着法树中含有以下两种着法，第1种着法最后形势从残局库知道是和局，第2种着法最后形势从残局库得知是红胜，因此在最初局面，红方通过引擎计算和残局库结合，决定走第2种变化。

回應15：yjr123   主題：Re:   2005/2/21 下午 06:48:07 

对于第2层意思，是想法缩小残局库的体积，事实上在残局阶段如果把所有可分胜负的局面记录下来，那么对于残局库中没有的局面也可以得出结论，那就是和局，如此则残局库体积大减，因为在很多子力配置下，可分胜负的局面是不多的，如单车对士相全、双车对单车士相全等等，对于子力相当的残局要建全残局库谈何容易，如车马有士相对车马有士相，但实际上去掉分不出胜负的局面，则剩下的局面和原来相比，则体积可能不是一个数量级的。

回應16：Pai   主題：Re:   2005/2/22 上午 06:09:59 

先就第一層做說明:yjr123所提已經相當接近我的實踐。基本上我的程式在搜尋時便會查詢殘局庫,根據結果而改变搜尋的方向。所以在約十步內若能達到殘局庫,其資料便可以被用到。所舉的例子便是一個很好的情形。
300+G是目前我有的資料。左右及红黑對稱都可處理。体積應該不是一個很大的問題。如果殘局對你而言夠重要,那硬碟便想對的便宜。yjr123兄所提的第二層想法將面臨盤面編碼的挑戰。Hash表的key並不是一對一的。當你把表增大到略為可用時,恐怕所省的体積已不值得你大費周章的另給一碼。而且你願意容許某種程度的錯誤,讓煮熟的鴨子飛了嗎?相形之下,硬碟便宜多了。:-)

回應17：yjr123   主題：Re:   2005/2/22 下午 12:17:24 

我借用HASH表的概念主要是表达第1层意思，就是要在运算过程中利用残局库，第2层意思主要是缩小体积，将残局库中的和局全部精简，并不是要改变数据结构，仅是在引擎利用残局库的时候，判断方法稍做修改，凡是在残局库查询中查不到的局面，作为和局。

回應18：yjr123   主題：Re:   2005/2/22 下午 12:36:38 

仍以前面这个残局为例，第1变例在残局库中查不到，作和局，第2变例查得到，为红胜，因此选择第2变例。
假定马士对象的残局库有200M，根据pai的残局库统计，红先可胜盘面占了23.39％，黑先可和的盘面占了94.29％，如果将和局精简，则只剩23.39M＋5.71M，体积仅为原来的15％，而所要做的仅仅是引擎查询残局库时，多了一个查询不到的情况，而这种情况只须统一作和局处理即可。

回應19：Pai   主題：Re:   2005/2/23 下午 08:09:48 

如果只保存紅先勝及黑先不和則將有二個問題:
一、 如何建立索引,讓盤面對應到資料?
二、 紅先負,黑先勝如何處理?

回應20：yjr123   主題：Re:   2005/2/23 下午 09:25:54 

第1个问题就是引擎要解决的问题，凡是所剩子力配置已经建立了残局库（如knb-ke），则根据索引去查询，由于将和棋局面精简掉了，因此多出了一种情况（查询不到），也就是对应不上，这种情况引擎全部将其作为和局处理。

第2个问题是全部有胜负的局面都必须保留，精简掉的只是和棋局面，也只有如此，软件才可以处理上述第1个问题。

回應21：yjr123   主題：Re:   2005/2/23 下午 09:45:13 

建议参考研究一下SaoLa的一个免费试验软件
http://www.nchess.com/download.php?file=eon.zip
摆出的局面残局库中有的，则立刻出现取胜最佳着法，如查询不到，则立即提示本局面为和棋。

回應22：Pai   主題：Re:   2005/2/25 下午 09:51:53 

"最近看了SaoLa附带的一个小软件EON，受到启发，单车对士象全的残局，全部数据库仅有270K，原来SaoLa的处理方法是仅记录有胜负的局面，这样单车对士象全的残局巧胜局面就不多了，凡不在数据库中的局面均是和局。"

"原来SaoLa的处理方法是仅记录有胜负的局面" -- 請問如何得知?我看起來比較像只紀錄一方的勝、負、和,然後用搜尋來補足其它資訊。這樣可用八分之一的大小來完成目標。我不知道如何只記錄部份資料而省空間。知道的人可否見示?

回應23：meifire   主題：Re:   2005/2/26 上午 12:33:05 

Pai兄,我刚刚(2月26日凌晨)给您发了一封信,请查收