pai的残局库推荐着法是有问题

yjr123

推荐着法都是一步杀！

http://lpforth.forthfreak.net/cgi-bin/endgame.cgi?2E2K34p1N28E6n299994k490

meifire

残局库推荐着法首先当然是看结果,如果一种走法的结果为和,另一种为胜,当然选可胜的;

其次看哪种着法可以最快的吃子,不单独考虑"将死"和"欠行",因为残局库认为出现这些情况后,就是一方被迫送吃自己的将/帅,包含在"吃子"这种情况里了.而在考虑吃子时也不会优先考虑将/帅被吃的情况.

这样来看上面的局例就明白了

象３進１ 00-003 *
象３進５ 00-003 *
象９退７ 00-003 *
象９進７ 00-003 *
馬７退５ 00-001
馬７退９ 00-001
馬７進５ 00-001
馬７進６ 00-003 *
馬７進８ 00-003 *

馬７退５/馬７退９/馬７進５之后,红方可以立刻马三进一吃象,而且形成的是另一个红可胜的局面

象９退７/象９進７/馬７進８ 之后,红马吃不到黑象,

象３進１/象３進５/馬７進６ 之后,红方如果吃象,则成和棋,因此对这六种着法,红方续着都是兵五平四,将6进1吃兵,马三进四吃将,即3着后吃子
因此,残局库推荐黑方走离吃子最远的几种着法,哪怕是被一步杀.

yjr123

楼上所说的就是残局库现在的判断标准，是存在问题的，残局库至少也应该考虑吃将和吃其他子是有区别的。

[此贴子已经被作者于2008-1-14 9:23:36编辑过]

meifire

为了减少计算量.

还有一个情况是为了避免被对方长将/长捉而绕很大的圈子去取胜.比如车马对单车库的最长取胜局面.

周运栋

我有一个很好的残局库算法，2年前就想到了，非常巧妙。

Pai

I am very interested to hear about it. :-)

周运栋

这个算法目前还可能存在问题，另外也不便于公开与透露，总之，我提个建议：您应该考虑更加完善，做到每个局面都有最短胜着法，和与负的着法无所谓最短。

Pai

In your method, how do you find the shortest routine to win if there is indefinite checking/chasing involved? How many moves do you count those? Not to reveal your whole method, do you mind share some thoughts on this specific question as it does bother me a lot.

zhaodi

PAI 有QQ号吗?通过QQ联系方便.周先生一般上QQ的.

Pai

I don't have a QQ account and I don't know how to obtain one. It is not popular outside of China, I guess.

Pai

我前一陣子就有看到這個討論。但是因為比較忙,所以到今天才上來回答。
meifire 其實對殘局庫的瞭解已經很透徹了。很多地方也解釋得比我清楚,所以我就從他的回答基礎上,
再加說明。

meifire:

"order的含义在残局库的主页上有说明.我理解是:在当前局面前往被吃子的局面的途中,
还要经过多少次弱势方可以长将或长捉的局面.

由此得到的几点推论:

對於只有一方有攻擊子的盤面，Order 都是 0,因为弱方无法长捉或长将

在order是正数时,value的值表示距离下一个弱势方可以长将或长捉的局面的着数.

当order 是正数,value为0时,弱势方的推荐着法都会造成长将或长捉对方,当弱势方被迫变着时,
order就会减少(感觉似乎应该是减1,但我发现过例子是减很多的),而value重新变为正值,
开始前往下一个长将或长捉局面,直到order为0,value也为0,则是到达吃子局面."

___________

meifire 的解釋清楚而正確。對order不見得只減1的觀察也是正確的。order會逐漸變小,通常在
換捉不同子時,減的數目較可能會大於1。

關於看起來像是錯的推薦走法,我己經被問很多次了。不少人因此而認為殘局庫的結論是錯的。
我一直想解釋清楚,但一直沒有用中文做過。一樣,我們從meifire的說明開始:

meifire:

残局库推荐着法首先当然是看结果,如果一种走法的结果为和,另一种为胜,当然选可胜的;

其次看哪种着法可以最快的吃子,不单独考虑"将死"和"欠行",因为残局库认为出现这些情况后,
就是一方被迫送吃自己的将/帅,包含在"吃子"这种情况里了.而在考虑吃子时也不会优先
考虑将/帅被吃的情况.

~~~~~~~~

會有看似錯誤的推薦走法,最主要根源於我最原先的一個設計決定。殘局庫可以記錄到吃將軍的步數
(distance to mate, DTM),或是到吃任何一子,而進入子殘局庫的步數 (distance to conversion,DTC)。
在考慮過象棋的特性,以及殘局庫製造的效率,我最後選擇了 DTC。原因如下:
1. 由於象棋有長將及長捉的規定, DTM 似乎不太能夠成立。每次長將或長捉應算幾步?
2. DTC 在程式的運行上有較高的效率。
然而在選擇 DTC 後,便帶來了一些人觀察到的不自然現象。由於吃子勝和將死被視為同等,
所以會有推薦走法出現一步殺的情形。在沒有更好的方法前,我只能選取我覺得最好的方法。

667

象棋殘局庫查詢系統

新增!

DTM 的説明
自從有了這個殘局庫後，陸陸續續有人提出有些局面在DTC(distance to conversion)殘局庫下，電腦建議的步伐 ，從人的思維來看很不自然。

原因在於長將及長捉對殘局庫的建立所造成的問題。根據亞洲規則，一子或多子長將或長捉一子，長將或長捉方不變做負。這在DTM(distance to mate)的步數判別上有困難。到底這種情況，要算幾步呢？
當初基於這個考量，我用了DTC的架構來建立殘局庫。在比賽中，長將、長捉方有二種選擇：一、不變做負。二、變著，不再長將、長捉。第一種情況，比賽立即結束。第二種情況，則要看後續的發展。當初不知道要如何解決這個問題，於是將就的用DTC來建造殘局庫，並引進order的概念。本來DTC的步伐計算，算到二個終點(value 0 或 1）
一、將死。
二、吃子。
我再加上第三種狀況：
三、長將或長捉。
因為第三種狀況，若弱勢方不變則做負，形同第一種狀況。這樣起碼庫做得起來。但也因此帶來一些負作用。對強勢方而言，不區分這三種狀況，有時會求快吃子而錯過可將死但稍長的走法。或有時會逼迫對方快進入長將或長捉的局面，但卻捨棄直接將死對方而稍長步伐的走法。即當(三）的value小於(一）、或（二）的value小於（一)時，從人的觀點來看，會覺得殘局庫建議走法不自然。畢竟象棋的目的在於將死對方，吃子或逼對方長將或長捉只不過是手段。然而這一切並不會影響每個局面勝、負、和的結論，只是在步伐建議上顯得不自然。當初建殘局庫目的在給象棋引擎使用，重在正確的勝、負、和結論，以及有效率的建造，並不知如何在DTM的架構上解決長將和長捉。
在經過長期思考後，我提出一個可能的解決辦法。在此提出來討論，讓大家可以看看是否能接受。基本上，我覺得長將及長捉將棋局的進展停住，可以視為停滯棋局進展的無效步。若不把長將及長捉的步數算入，DTM便可以成立了。於是我將原來的程式做修改，建造了一些DTM的庫。DTM的庫去掉了order的概念，所以永遠order都是0。當長將或長捉時，value會加一，而不是平常的減一。優勢方在這時一定有方法再使對方進入可長將或長捉的局面。劣勢方可選擇繼續長將或長捉，或選擇value變小的走法而使棋局繼續進展。這樣的殘局庫，走步從人的角度看自然多了。有興趣的人可以參考下列的連結，看是否DTM庫解決了這些人提出來的質疑。

http://www.hgchess.com/bbs/forum ... 17739&mobile=no

http://tieba.baidu.com/p/3198720433?pn=0&

我還要補充一點：在將長將及長捉視為無效步的觀念下，可以建立另一種沒有order的DTC庫，其value為到將死或吃子的距離。不過，先讓我們看看把長將及長捉視為無效步的概念是否行得通。