このタイトルで記事を書けという電波を受信したので手短に書く。
将棋ソフトで「mate 7」のように表示されることがある。これは、どう応じても7手で詰むという意味である。しかしこれが即詰みによるものなのか、必至によるものかはわからない。ともかく最長でも7手で勝つということだ。
しかし、ここでいくつか議論が起きる。
「即詰み」とは何なのか？
これは難しくない。その局面から勝つ側の指し手がすべて王手になっていることである。
対して、「必至」の定義は難しい。
mate X = 「最長でもX手で詰む、即詰み」+「最長でもX手で詰む、必至」
と定義すれば、「王手」の定義と合わせると、「必至」の定義として「その局面から勝つ側の指し手がすべて王手にはなっていない」というのが得られる。
私はこの定義でも良いと思うのだが、世間で「必至」と言う場合、この意味では用いない。
例えば、相手がどう応じても3手後に宣言勝ち出来るとき「3手必至だ」などとは言わない。
また、次に自分の手番が回ってくれば頭金で1手詰みで、相手は受けなしなのが、相手は歩を18枚持っていて、こちらの王の頭に歩を叩き、それを交わして、歩を成って、同玉という、1歩損と引き換えに詰みを4手伸ばせるとしよう。このとき4×18+1 = 73で、「73手必至がかかった」のように言う人はいない。いないよね？
また、我々はそういう風に「必至」と言う用語を使いたくない。この場合、「手番が回ってくれば1手詰みで、かつ、受けは無い。こちらの玉は、王手は続くが詰まない」のような感じで言われたほうがわかりやすい。つまり「必至」という定義がどうであれ、この用語を使うには適切でない状況が多々存在するということである。
「N手必至」と「N手すき」とをどう使い分けると良いのかという話はまたの機会にするとして、棋譜検討の際にmate 7が「即詰み」によるものか、そうでないかぐらいは区別されていて欲しいという将棋指しの要望は理解できる。何故なら、即詰みによるものだとわかっていれば、それは純粋な詰将棋問題であり、王手の指し手だけを考えれば良いからである。また場合によっては局面図自体に詰将棋としての価値も出てくるだろう。
「即詰み」であるのか、そうでないのかは区別するのは、技術的には簡単である。例えばmate 7だとわかった時点で、詰め将棋ルーチン(df-pnによるものなど)を呼び出して、即詰みかどうかをチェックする。df-pnによる詰将棋ルーチンは即詰みの有無は教えてくれるが、その手数は教えてくれない。まあいい。それで、即詰みだとわかったなら「即詰み(最長7手)」さもなくば「必至(最長7手)」とでも出力してくれると便利なような気はする。
とは言え、USIプロトコルでは、この区別をして出力する記法が用意されていない。エンジン側だけ対応してもどうにもならない。
こういうことを考えていると、先日の「千日手」の読み筋の件を含め、そろそろUSIプロトコルの拡張をしていきたいのだが、それをするには、GUI側の協力が必要だ。プロトコルだけ拡張してもそれに対応するGUIがなければ意味をなさない。
仕方ないので将棋用のGUIを作ろうかと思っている。拡張USIプロトコルはオープンな場で議論して仕様を決めて、そして、その拡張USIプロトコルを実装したGUIをオープンソースで提供するといいんじゃないかと思っている。思っているだけだ。まだやるとは誰も言ってない。
こちらの玉は、王手は続くが詰まない＞
対人間の対局でミスを狙うならわかりますが、ソフト同士や検討モードでこの王手ラッシュが必要なのか疑問です。
なので私は、王手を続ければmate Xの値が大きくなってしまうので検討するときは、局面編集で勝った方の玉を取り除いて再度探索させます。
mate Xのとき逆転がありえなければ勝ってる方の玉を無いとみて探索するのをデフォルトにしてほしいですが、自玉の即詰みを見落とす可能性はいなめないですね。。。。
詰めろかどうかは、手番を反転させて即詰みがあるかどうかを調べれば良いだけなので、実装が簡単ですし、棋譜解析のときに「詰めろ(7手詰み)」のように表示されると便利かも知れませんね。また手数を伸ばす王手しか出来ない場合(この判定は簡単ではないかもですが)、「詰めろ(7手詰み)・受けなし」のように出力されると便利かも知れませんね。
LinuxやMacOSでも動くGUIが欲しい、Javaより良い感じのクロスプラットフォームなGUI無いの、とか話はちらほらありますけど、GUI周りとかクロスプラットフォーム周りとか良く分からないですよねぇ。子プロセス周りとか、グラフィック周りとか、ファイル周りとか、プラットフォーム固有の部分がどの程度良きに計らってくれるのかも分からないし。
仮にマルチプラットフォームのGUIを作るとしたらどの辺がお勧めだったり駄目だったりするんでしょうね。
Electron https://electron.atom.io/
PyQt http://www.riverbankcomputing.com/software/pyqt/
私はElectronで作ろうと思ってます。(作れるかどうかはまだわかりません)
とりま、レンダリング部分をHTML5ベースにしておけば、他のフレームワークと差し替え出来なくもないですし。
では、Node.jsやElectron周りもチラチラ見ておいた方が良さそうですね。有り難うございます。
はい(｀･ω･´)ゞ Mizarさん、頼もしい。
linuxでも動くGUI。
欲しいです。
Electronで作れば動きますね…たぶん。
拡張されるなら、対局用だけでなく、将棋研究用、ソフト開発用のプロトコルも拡張したいような。
千田先生ご要望の評価値テーブル可視化機能用プロトコルとか。
評価関数がKPPTとは限らないので色々面倒くさいような気が…。
たしかに。駒割のみ、技巧と3駒と４駒に統一的なインタフェースはなんぞやと。
しかし駒の配置と手番から評価値を出すという基本構造に変化なければ、最小限の要件とインタフェースは定義可能な気がします。
最小限だと結局研究に不十分じゃんとなると無駄骨ですが…。
即詰みの有無の判定についてなのですが、即詰み手数よりも必至の手数の方が少ない場合でも大丈夫なのですか？
また、ステイルメイトが現行ルールにいう「詰み」に含まれなくても、語感からは「メイト」に含まれてしまいそうな点が気になってしまいます。
> 即詰みの有無の判定についてなのですが、即詰み手数よりも必至の手数の方が少ない場合でも大丈夫なのですか？
探索エンジン的には先に見つけたほうなので、即詰みがあっても、必至のほうが手数が短ければそちらを見つけてmate Xと出しますね。このとき詰将棋ルーチンを呼び出すと詰むと判定されて、X手での即詰みと見えてしまいますね。実際はX手での必至なのに。うーん..きちんとした詰将棋ルーチンを用いて手数まで計測しないと駄目かも…。stalemateもおっしゃる通りですね。まあstalemateはレアケースなのであまり問題とはならないかも知れませんが。
Electron製の将棋GUIめっちゃ期待です(`･◡･´)
とりま、次の電王トーナメント終わってからですな〜。