ShogiDroidの解析モードで、やねうら王・魔女のPVが1手目までしか出力されないことがあるという書き込みがなんとかちゃんねるにあった。
やねうら王では、PvIntervalを0にすると、0[ms]ごとにPVを出力するようになって、PV自体は反復深化のiterationごとに出力されるようになる。このパラメーターはdefault値は300になっていて300[ms]ごとにPVを出力するようになっている。あまり勢いよく出力すると将棋所の出力が詰まることがあるのでこのような対策を入れてある。
魔女ではこの部分は200[ms]に固定されているようで、どうやっても200[ms]以内で出力はされない。
ゆえに、1手200[ms]より短い時間で棋譜解析をやろうとするとPVの出力がきちんと得られない。
いまどき将棋ソフトはアマチュアの将棋ファン(アマ初段ぐらい？)よりは十分強いので100[ms]程度の思考時間であっても、棋譜解析としては十分であろうから、そう考えると魔女の200[ms]の部分は変更できて欲しいような気はする。
それとは別に、やねうら王で上述のように設定を変更してもやはりPVが1手しか得られないことがあるらしい。
そのなんとかちゃんねるによると、やねうら王は、fail low/fail highしたときにも(lowerbound/upperboundの文字列を付与して)PVを出力するのだが、これをShogiDroidが拾っていて、これをPVとして表示するので、PVの指し手が1手か2手しか得られないことがあるようだ。
やねうら王に、fail low/fail highに関して、ログを出力しない設定をつけるべきなのか、fail low/fail highはShogiDroid側が無視する(ような設定を追加する)か、どちらかではないかと思うのだが、とは言え、反復深化のなるべく最後のほうに出力したPVこそが本当の読み筋なわけで、fail low/fail highだからと言って無碍にていいものかよくわからない。かと言ってPVの指し手が1手では人間にとって読み筋として参考にならない。
どうなっているのが良いのか意見をコメント欄で教えて欲しい。
— a/source/engine/2016-mid-engine/2016-mid-search.cpp
+++ b/source/engine/2016-mid-engine/2016-mid-search.cpp
@@ -2192,6 +2192,8 @@ void Thread::search()
&& Time.elapsed() > 3000
// 将棋所のコンソールが詰まるのを予防するために出力を少し抑制する。
&& (rootDepth < 3 || lastInfoTime + pv_interval rootMoves[0].pv.size() > 3
+
)
{
lastInfoTime = Time.elapsed();
pvたまったところで出すというのは？
そういう問題じゃない？
> pvたまったところで出すというのは？
出力が詰まるのは、1行ずつ出すからではなくて単位時間当たりに出す量が多すぎるからだと思います。なので、何らかの戦略に基づいて出力を省略する必要があるのですが、簡単ではないですね。
bestmoveを返す直前には必ず最後のiterationのPVを出力するのが良いのかも知れませんが、その処理、わりと面倒くさいですね。最後のiterationのPV、出力しないときにも文字列として保存されている必要があることになりまして…。
pvが短ければUSI::pv呼ばなくてもいいかなと思ったんですが。ソース差分崩れてますね(´・ω・`)
pvの処理もいろいろ大変なんすね。
pvが短いかどうかはpv配列調べないとわからないですね。まあ、短ければ出力しないというのはアリだとは思いますけども。あとはnull moveですね。null moveを出力する手段がUSIプロトコルでは存在しないのです。読み筋に[1手パス]とか表示されてもいいような気はするのですが…。
UCIだと”0000″,gpsfishは”pass”がnull moveみたいです。
なるほど。USIでも”pass”を出力させて欲しいですね…。
fail low/fail highのPVには無碍にしていいやつと無碍にして駄目な２パターンあると言ってますか？
fail highした場合のPVの初手、次の1手としては、fail highする前のPVの初手よりは良い手ではないかと。
これ無視するも出力しないもbestmoveとの関係が崩れるのであんまり良くないですね。
時系列表示をすれば問題解決できそうですけど、
切り替え方法とか、スマホでそこまでするのか・・・という
そうですね。まあ、lowerbound/upperboundは無視する設定がShogiDroidについているのが一番現実的かとは思います。
ちょっと話がずれますが、PVが短くなるのはどういう仕組みでそうなるんでしょうか？
αβ探索には探索窓という概念がありまして、探索の結果の評価値vが、-200 < v < 200の範囲だと仮定して探索することが出来ます。このときの探索窓は(-200,200)です。こうすると早く探索結果が得られるのですが、ところがこの範囲外の値が返ってくることがあります。それがfail lowとfail highで、そのときは探索窓を広げて探索しなおします。このfail lowとfail highしたときにPVが短くなります。(PVの途中の手でvが範囲外であることが判明したため)
ここに書く話じゃないのかもしれませんがツイッタのアカウント凍結して復活できない。
ネタ募集みたいな事書いてましたが今年の電王トナメントに出場するRAPUNZELのアピール文書に書いてあるSibling Conspiracy Number Searchについてどう思いますか？
> ツイッタのアカウント凍結して復活できない。
何の悪さをしたんですかｗ
> Sibling Conspiracy Number Searchについてどう思いますか？
詰将棋でよくあるpn-search(proof-number search)を普通の探索に使ったような感じで概念的には意味もあると思うのですけど、いまのStockfishの探索って、相当、細かいところまでチューニングされていますから、性能を比較するのは可哀想な気がします。