Hatena::ブログ(Diary)

Bonanzaソース完全解析ブログ

2011-12-18

USIプロトコルへの様々な疑問にお答えします

USIプロトコルへの様々な疑問にお答えしますを含むブックマーク USIプロトコルへの様々な疑問にお答えしますのブックマークコメント

USIに文句を言うだけ言う

http://d.hatena.ne.jp/merom686/20111217


まあ、USIプロトコルがいろいろアレであることは、いまさら言うまでもないことなのですが、なぜこんなプロトコルがコンピューター将棋の標準になっているかと言うと、将棋所という素晴らしいUIが採用したからに他なりません。


その将棋所の作者はコンピューター将棋を自らは作っておらず、何が必要かあまりよくわかっていないのだと私は理解しています。


まず、将棋所のサンプルについているLesserKaiのソースもかなりでたらめなコードです。例えば、将棋所のサンプルのLesserKaiのソースで、時間をparseしているコードは次の部分です。

void USIUtil::ParseAllTimes(const char *buf, int SorE)
{
	string goStr = buf;
	if (goStr.find("infinite") != string::npos) {
		isInfinite = true;
	} else {
		isInfinite = false;
		int pos = goStr.find(" btime ") + 7; // 7 = strlen(" btime ")
		int senteTime = ParseTime(buf + pos);
		pos = goStr.find(" wtime ") + 7; // 7 = strlen(" wtime ")
		int goteTime = ParseTime(buf + pos);
		remainTime = SorE == SELF ? senteTime : goteTime;
		pos = goStr.find(" byoyomi ") + 9; // 9 = strlen(" byoyomi ")
		byoyomiTime = ParseTime(buf + pos);
	}
}

驚くべきことに"byoyomi"という文字列が必ず書かれていることを期待しており、"byoyomi"という文字列が書かれていない場合のことは全く考えてもありません。"byoyomi"という文字列がない場合、findは-1を返し、-1 + 9でpos == 8となり、なんと"btime"の直後の数字を"byoyomi"の数値として解釈してしまいます。


まるで、「"byoyomi"は必ず書くものであり、書かなかったときの動作はどうなっても知らんよ」と言いたげです。


将棋所もこれと同じぐらいひどいコードが書かれていることは想像に難くなく、思考エンジン側から少し変な文字列を送るだけで将棋所がクラッシュするのは、このようなエラーチェックの甘さに起因するものでしょう。


解釈できない文字列が来たら、警告を出した上でデバッグ用のログには書き出すだとか、そういう配慮がないので、思考エンジンのデバッグ時に非常に使いにくいです。将棋所はユーザーフレンドリーではありますが、思考エンジンの開発者フレンドリーでは決してありません。


自分で思考エンジンを書いている人ならば、こんなひどい仕様にはしないと思うのですが。


さて、以下では冒頭で挙げたmerom686さんのUSIプロトコルへの不満に対して私の理解を書いておきます。

ponder(先読み)は、それ自体をUSIの仕様から削除すべきだと思う。

予測読みのやり方は、エンジン作者が考えるべき問題だ。

そのやり方を1種類に決めてGUIがサポートしてはならないと思う。

これは使いやすさ以前の問題だ。

ponderの仕様が非常にまずいことは私が以前書きました。( http://d.hatena.ne.jp/LS3600/20111029 ) 結論としては、ponderを使うなってことです。USIプロトコルから削除すべきは私もそう思います。

setoptionで、エンジン側で設定を保存する必要があるのがおかしい。

ファイルに設定を保存するというのは、それだけで相当な手間である。

USI_PonderとUSI_Hashだけ保存しなくていいというのも一貫性がなく面倒だ。

そもそもハッシュサイズを1MB単位で指定するという仕様も変だ。

1MB単位ではなく1byte単位で指定できるようになっているべきということですかね?

単位がMBになっているのは文字数を少しでも減らす、みたいな意図はあるのかも知れません。

1MB単位ではなく2**N byteのNを指定させろという意味でしたら、それは私は反対です。置換表は、通常探索用・詰将棋探索用など複数の置換表を持つことがあり、それぞれを適当な配分で確保したいことがあるので2**Nしか指定できないと困ります。

position

毎回全ての指し手を書く必要があるのは糞。

N手の将棋でやり取りされるpositionのデータ量がO(N^2)になる時点でキモい。

これはまあ、そうですね。入玉模様で1000手ぐらいの将棋ですと特に…。

USIでは、棋譜をSFENという方式で表す。

これは、USIがUCIチェス用のプロトコル)を元にしているので仕方ないのだが、

日本人は8hがどの升を表すかわからないし、パーサを書くのもプチめんどくさい。

飛車がRookのrで表されるのも、チェスの知識を要求される。

Bonanzaソースコード上で飛車はRookとなってて、Bonanzaソースコードに慣れ親しんでいるとそのへんはどうってことはないですが、升の表記がわかりにくいのは同感です。思考エンジンをデバッグしているときに、すごく困ります。

merom686 「対局ごとに必要な初期化」はgameover直後にするのがいいと思うのです。最初のisreadyでは「起動時」「対局ごと」両方やるとして。

http://d.hatena.ne.jp/merom686/20111217/1324123889#c

対局ごとに必要な初期化はisreadyでやって全然構いませんけどね。isreadyに数時間かかろうと問題ないようなので。isreadyは対局のたびに送られてきますし、連続対戦であればgameoverのあと即座にisreadyが送られてきますので。

go infinite

次にstopが送られてくる前にbestmoveを返してはいけません。

将棋所:USIプロトコルとは

細かいところだけど、不安になるエンジン作者がいたらいけないので。

勝ちを読み切った場合などは当然bestmoveを返していいはず。

返してはいけません。

例えば、次の問題です。(将棋所付属のLesserKaiのソースコードのコメントより抜粋。)

// 人間対エンジンで、エンジンが予想した手を人間が指すとponderhitが送られ、

// その後、まだエンジンが継続して思考している時に「すぐ指させる」ボタンを押すと、

// stopが送られてくる。このように、ponderhitとstopが続けて送られてきた場合、

// ここでは何も返さず、その次のstopに入ったところで手を返す。

実は、上記のコメントに書かれているようなことはうまく実装できません。

ponderhitが起きたときに、ponderのときに指定されていた思考時間設定のまま思考を継続しているわけで、ちょうど思考が終了してbestmoveを返す瞬間にstopが送られてきたからと言って、「何も返さず」というのが無理な話で、「もう返してしまっている」こともありますし、次のstopでもbestmoveを返すのですが、それがそのstopに呼応するbestmoveを返していることにはならないケースがあります。

たとえば次のようなシーケンスを考えてみましょう。

ホスト側     思考エンジン側

go ponder

ponderhit

※ 思考エンジン側はponderhitして、思考が終了したのでbestmoveを返す

       bestmove XXXX

stop

※ ホスト側には思考エンジン側が返したbestmove XXXXが、stopに呼応したもののように見える。

position XXXX

go

       bestmove XXXX

※ 思考エンジン側はstopコマンドが来たようなのでbestmoveを返すが、これが、ホスト側からすればgoコマンドに対する応手のように見える。

とまあ、bestmoveを返して良いコマンド(ponderhit,stop)を思考エンジン側からの応答を待たずにホスト側が2つ続けて送信してしまうのは、プロトコル上の欠陥であり、シーケンス的に見て破綻しています。

要するにponderhitに続けてstopを送ることがあるというのは仕様上の欠陥だと私は思います。


同様の理由により、"go infinite"で「次にstopが送られてくる前にbestmoveを返して」しまいますと、bestmove返すのと同時にstopが送られてくるとホスト側にはstopに呼応するbestmoveのように見え、次の局面図を思考エンジン側に送信するかも知れないですが、思考エンジン側はそのあとstopコマンドを解釈し、bestmoveを再度返しまして、これがホスト側からすると次の局面図に対するbestmoveのように見えます。

ゆえに、いかなるときであっても「次にstopが送られてくる前にbestmoveを返して」は、いけません。


usinewgame

このコマンドの意味するところがよくわからない。

異なる対局を始めるからハッシュをクリアしたほうがいいとか、

対局が始まったからsetoptionなどのコマンドを受け付ける義務がなくなったとか、

いくつか考えられるが、仕様に明示されていないと使えない。

ぶっちゃけ、なくてもいいコマンドなので、その辺りの説明は欲しい。


対局中に(思考中に)setoptionで置換表サイズを変更されても困りますし、ponder有りから無しに変更されても困ります。対局中に、それらのコマンドが来ないことを保証するために、対局中と非対局中とでは別の状態(決定性有限オートマトン的な意味で)でなくてはなりません。usinewgame〜gameoverはそういう意図だと思います。このへんはまあよく考えてあるなぁとは思うのですが。USIのドキュメントに有限オートマトンで状態遷移図を書いて、この仕様についてもう少し明確にしてあったほうがいいような気は私もします。


以上、ざっとUSIプロトコルについての疑問に答えてみました。思考エンジンを実装する人の参考になれば幸いです。

merom686merom686 2011/12/18 13:31 > ハッシュサイズ
「1MB単位か2**N byte単位かそれ以外かはGUIではなくエンジン作者が決めるべき」という意図です。
私が2**N byte以外のケースをよく知らないため、あのような表現になってしまいました。

> isreadyは対局のたびに送られてきますし、
なるほど。同意です。
しつこいようですが、私が言いたかったのはそれならそれで仕様に明記してほしいということです。

> ※ ホスト側には思考エンジン側が返したbestmove XXXXが、stopに呼応したもののように見える。
これは理解できますが、
goより前に来た(この順序は保証できますよね?)stopに反応するのはエンジンが悪いと思います。
また、この問題はgo infiniteに限らずgo btime 0 wtime 0 byoyomi 1000でも起こるのではありませんか?

私の意見は、「go infiniteで、stopが送られてくる前にbestmoveを返してよい」という仕様がよく、
それで問題が起こるようならgo infinite以外の仕様を変えることで対応するべき、というものです。
理由は、そうしないと時間制限なしの検討モードで困るということと、
他のgo ***ではいつbestmoveを返してもいいのにgo infiniteだけ違うのは変だと思うからです。

> usinewgame
なるほど、よくわかりました。

LS3600LS3600 2011/12/18 17:29 > 「go infiniteで、stopが送られてくる前にbestmoveを返してよい」という仕様がよく、

ああ、意味がわかりました。もしUSIプロトコルを作りなおすならばという仮定の話であるなら、それには私は賛成です。

「goに対してbestmoveは一回しか返さない。(stopが何回送られてこようが、goに対して1回bestmoveを返せば、思考エンジン側はそれ以上bestmoveを返してはならない。)」というのを守って、かつ、ホスト側もそのように解釈(思考エンジン側からbestmoveが来るまで思考エンジンに次のgoを決して送らない)」するなら問題はないのです。

USIプロトコルの仕様としてこのことが明記されていないので、将棋所はたぶんそういう実装にはなっていない気がしますし、LesserKaiのソースもコメントを読む限りそういうつもりで書かれていないように見えますし、他のUSI対応のホストもそういう仕様にはなっていない気がします。

ゆえにstopが来る前には勝手にbestmoveは返さないほうが無難というのが私の認識です。

LS3600LS3600 2011/12/18 17:37 > 私が2**N byte以外のケースをよく知らないため、

余談ですが、置換表は2**N byteでないことのほうが多いです。なぜなら、たとえばBonanzaであれば16byte*3 = 48byteが1エントリーであり、このエントリーへのindexが2**Nになるようにするため(index = hash & 0xffffff;のように書きたいため)、置換表自体のサイズは2**N byteにはなりません。

ゆえに指定された置換表サイズに収まるようなNの値を計算するようなコードが必要になります。

あとはまあ、通常探索用の置換表とdfpnの置換表は確保するサイズを4:1にしようかだとかまあ何かそういうことをするので、結局ユーザーは「1GBに収まる範囲で自由に使って」というようにアバウトに上限を指定し、思考エンジン側は、そのサイズに収まるように最大サイズの置換表を確保するような動作になるのではないでしょうか。

merom686merom686 2011/12/18 18:47 > go infinite
簡単に勝ちを読み切れる局面をLesserkaiでgo infiniteさせてみました。
すぐに読み切りましたが、将棋所には思考が完了したことを知る術がありません。
(ユーザーはCPU使用率や読み筋の様子でわかるので中断ボタンを押しますけど)
これがUSIの仕様に沿った動作であることはわかりました。
「stopが来る前には勝手にbestmoveは返さないほうが無難」な理由もわかりました。

では、このような仕様になっている理由をどう考えているのですか?
このエントリで言及されている問題は、制限時間付きのgoでも同様に起こるので、
理由になっていないと思います。
「理由はないけど仕様がそうなっている」というのならそれで構わないのですが。

(というか、私は「制限なし」の代わりに「制限あり99時間」を使えばいいのですね…)

> このエントリーへのindexが2**Nになるようにするため
M*(2**N)という意味で誤って2**Nと書いてました。すみません。
他、置換表についてはとても参考になりました。

LS3600LS3600 2011/12/18 21:00 > では、このような仕様になっている理由をどう考えているのですか?

合理的な理由は、私には思いつかないです。

USIプロトコルの原案を考えた人(Tord Romstad氏)は、Glaurungというコンピューターチェスを作っていまして、たぶん、氏は、goコマンドに対してはbestmoveは1回 *のみ* 返すということを暗黙の了解のものとにUSIプロトコル原案を書き、そして実装しているのではないかと私は思います。[要検証]

USIプロトコルを将棋用にリメイクした人(将棋所の作者)が、コンピューター将棋の思考エンジンを自分で書いていないため、この部分に対する理解が欠落しており、将棋所では残念な実装になっているのではないかと私は想像します。

まあ以上は私の勝手な想像で、もしかしたら、Glaurungのほうも、同様に残念な実装になっているのかも知れません。

ともかく、将棋用のUSIプロトコル対応のホストプログラムとして、このへんは将棋所 & LesserKaiを規範とするしかなく、お手軽に思考エンジンを開発したいコンピューター将棋開発者には、USIプロトコル対応が必須課題でして、まあ、コンピューター将棋の開発者は仕方なしに使っているのが実情だと思います。

こんなしょーもないプロトコル、将棋所のようなデファクトスタンダードなUIが対応しているのでなければ使いたくもないというのが私の本音です。かと言ってCSAプロトコルのほうのダサさ(時代遅れ加減)は、USIプロトコルの比ではありませんので、CSAプロトコルを使うという選択肢はいまさら無いでしょうね。

思考エンジンを作っている将棋に造詣の深い人が、もっとマシなプロトコルを策定して、open sourceで将棋所レベルのUIを作ってくれるといいのですが…。(ちらちらとmeron686さんのほうを見ながら)

merom686merom686 2011/12/18 21:38 詳しい説明ありがとうございます。納得できました。
ところで、どうでもいいことですが私の名前をtypoしていませんかw(CPUのMeromです)

> open sourceで将棋所レベルのUIを
私もコンピュータ将棋には思い入れがあるので、当然ながらやりたいと思っています。
が、色々作ってみたことや、今回のやり取りを通しても、力不足を痛感しています。
まあそりゃそうなんですけどね。とりあえずUSIのGUIを作ろうとしているところです。

LS3600LS3600 2011/12/18 22:29 > ところで、どうでもいいことですが私の名前をtypoしていませんかw(CPUのMeromです)

はい、すみません。(´・ω・`) さきほど気づいて本文のほうは修正させていただきました。

> とりあえずUSIのGUIを作ろうとしているところです。

USIにも対応させて、かつ、拡張USI by merom686 にも対応させるのがよろしいかと。

私の将棋所での大きな不満点は、分岐のある読み筋を表示できないことや、読み筋のpass(null move pruningならPVがpassになることもしばしば)を表示する手段が無いこと、1手前の読み筋をUI上で表示できないこと、「X手の詰めろ+読み筋」のようなものを表示する機能がないこと、連続対戦のときに個別に持ち時間を設定できないことなどです。

だんだん作りたくな〜る。作りたくな〜る。(催眠術)

merom686merom686 2011/12/18 22:47 作りたくはなってますよ〜。またいつかアドバイスをいただけたらと思います。

将棋所の作者将棋所の作者 2011/12/21 19:56 ちょっと遅れましたがコメントします。

>まるで、「"byoyomi"は必ず書くものであり、書かなかったときの動作はどうなっても知らんよ」と言いたげです。

Lesserkaiは将棋所で使うことを前提にしているからそう書いただけのことですが、それがそんなに問題でしょうか?

>将棋所もこれと同じぐらいひどいコードが書かれていることは想像に難くなく、思考エンジン側から少し変な文字列を送るだけで将棋所がクラッシュするのは、このようなエラーチェックの甘さに起因するものでしょう

Lesserkaiはサンプルなのでかなり適当に書いていますが、将棋所では受信した文字列のチェックはずっと厳しく行っています。それに、USIと関係ない文字列が送られてきたら無視する(デバッグウィンドウには表示しますが)だけです。
もしかして、日本語を送っていませんか?

LS3600LS3600 2011/12/21 22:05 > Lesserkaiは将棋所で使うことを前提にしているからそう書いただけのことですが、それがそんなに問題でしょうか?

私は問題だと思います。

例えば、第三者がUSIプロトコル準拠のホストプログラムを書こうとしたときに、そのホストプログラムで"byoyomi"を送らなければLesserkaiが誤動作します。

すなわち、この意味においてLesserkaiは純粋なUSIプロトコル対応のプログラムとは言えないのですが、かと言って将棋所専用の思考エンジンということもなく、一応USI対応のソースコードに見えます。

現状USIプロトコルの準拠の将棋ホストプログラムは将棋所とLaramieぐらいしか実在せず、Laramieは完成度において将棋所に劣りますから、実質的に将棋所が唯一のUSIプロトコル対応のホストプログラムは存在しないような状況です。

その将棋所に標準でバンドルされていれば、これがUSI対応の思考エンジンのサンプルだと思うのは当然ではないでしょうか。その規範にすべきソースコードで"byoyomi"が絶対に付与されていることを前提とした書きかたがされていれば、USIプロトコルでは"byoyomi"は絶対に付与されているのだと理解する人が出てきてもおかしくはありませんし、また、Lesserkaiのソースコードをコピペして自分の思考エンジンをUSI対応にしようとしたときこのままのコードでは「USIプロトコル対応」を謳うのはまずいです。

普通、他人のソースコードをコピペしてプログラムを書くことはあまりないかも知れませんが、Lesserkai自体は使用許諾条件は「れさぴょん」に準じるわけで、「れさぴょん」は、少しでもソースコードを改変する限りは自由に使って良いという使用許諾条件になっていますから、このLesserkaiのソースコードをそのまま自分の思考エンジンに組み込むことは十分に考えられるシナリオだと思うのです。

そうやって組み込んだときに、他のUSIプロトコル対応のホストプログラムでは正常に動作しないということは十分ありうるのです。

そういう意味では、Lesserkaiが純粋なUSIプロトコル対応になっていない部分については、問題だと思いますし、そういう情報を誰かがブログ記事か何かとしてまとめてあるといいのになぁとは思います。

LS3600LS3600 2011/12/21 22:05 > Lesserkaiはサンプルなのでかなり適当に書いていますが、将棋所では受信した文字列のチェックはずっと厳しく行っています。それに、USIと関係ない文字列が送られてきたら無視する(デバッグウィンドウには表示しますが)だけです。
もしかして、日本語を送っていませんか?

送っています!大威張りで言うことではないとは思いますが、送っています!

まず、思考エンジンのデバッグで一番表示したいものは何かというのを製作者サイドに立って考えてみていただきたいのですが、デバッグのときに一番表示させたいものは次の二つです。

・盤面
・指し手

これ以外にも表示させたいものはそのときそのときでいろいろあるでしょうけども、基本的にはこの2つは頻繁に表示させたいわけです。そのためにデバッグのときに標準出力に盤面や指し手を日本語(漢字)を用いて表示させている開発者は多いはずです。

sfenやCSAを出力するといったんコピペして別のソフトで確認する必要があるのでダイレクトに視覚的に確認しようと思うと、「7六歩」のような日本語になります。このような意味で日本語を直接表示したいわけです。

ともあれ、将棋所の実装として
・日本語を送るとクラッシュする
・2バイト文字列以外は思考エンジンからの文字列を厳しくチェックしている。
・思考エンジンからの関係のない文字列はデバッグウィンドウには表示している。
の3点の情報がわかっただけでも一人の開発者として、とてもありがたいです。(これはとても貴重な情報なので、将棋所の思考エンジンの開発者向けの情報として将棋所のページで公開するに値すると思います。)

本当は将棋所に日本語文字列が送れて、送られてくる日本語文字列のコードセットをsjis,euc,utf-8,utf-16あたりから選択できるととても良いのですが…。

将棋所の作者将棋所の作者 2011/12/21 23:12 >実質的に将棋所が唯一のUSIプロトコル対応のホストプログラムは存在しないような状況です。

であれば、他にGUIが存在しないのですから、何の問題もないと思います。
だいたいサンプルなんていうのは大枠を示すものであって、そんな細かいことまで問題にしても仕方ないでしょう。れさぴょんだって細かい問題点はたくさんあるでしょうが、そんなことより、あれが存在したからプログラムを作れたという人はたくさんいるわけです。Lesserkaiもそれと同様に、USIに対応するための参考として公開しているだけで、もし問題だと思うなら自分で修正して下さい、という程度のことしか言えません。

>もしかして、日本語を送っていませんか?

>送っています!大威張りで言うことではないとは思いますが、送っています!

そうでしたか。といっても、日本語を送ると必ず落ちるというわけではないので、私もこの条件を見つけ出すのにちょっと時間がかかりました。まず、単に

printf("日本語\n");

というように書くと落ちる可能性が高いです。この場合、将棋所が文字列を受信する前の段階で落ちてしまうので、こちらではどうにもなりません。回避方法としては、

printf("debug 日本語\n");

のように、半角英数字のあとに日本語を書くか、もしくは

printf("\n");
printf("日本語\n");

のように、一度改行を入れてから日本語を書くといいようです。あとで「エンジン作成時の注意点」に追加しておきます。

あと、ついでですが、

>その将棋所の作者はコンピューター将棋を自らは作っておらず、何が必要かあまりよくわかっていないのだと私は理解しています。

これは事実ですので否定しませんが、

>こんなしょーもないプロトコル、将棋所のようなデファクトスタンダードなUIが対応しているのでなければ使いたくもないというのが私の本音です。

>思考エンジンを作っている将棋に造詣の深い人が、もっとマシなプロトコルを策定して、open sourceで将棋所レベルのUIを作ってくれるといいのですが…。

であれば、どうしてやねうらおさん自身がプロトコルを設計しないのか不思議に思います。コンピュータ将棋にすごく造詣の深い方ですし、USIプロトコルの問題点も具体的に指摘しているわけですから、完璧なプロトコルを設計できるように思います。そうすれば、そのプロトコルを元に、誰かが素晴らしいGUIを作ってくれるかもしれません。期待しています。

LS3600LS3600 2011/12/22 00:16 >>実質的に将棋所が唯一のUSIプロトコル対応のホストプログラムは存在しないような状況です。
> であれば、他にGUIが存在しないのですから、何の問題もないと思います。

今日のコメント欄のmerom686さんのように、USIプロトコル対応のホストプログラムをこれから作ろうという人は何人かいるわけで、そういう人が余計なところで躓かないようにするための配慮が必要だと私は思います。

> だいたいサンプルなんていうのは大枠を示すものであって、そんな細かいことまで問題にしても仕方ないでしょう。

Lesserkaiに関してはコピペ自由なソースコードなので、このソースコードをコピペして自分の思考エンジンをUSIプロトコル対応にする開発者は少なくないはずです。(今後も含めて考えますとそういう開発者は増え続けるでしょう。) この意味において、単に思考エンジンのサンプルである「れさぴょん」とは意味合いが全く違います。

彼ら思考エンジンの開発者の時間を損失させないためにも、USIプロトコルに準拠した適切なソースコードを提供してあるほうがいいに越したことはありませんし、LesserkaiのソースでUSI対応に関して問題のある箇所があるなら、どこかのブログ記事か何かとして情報がまとまって存在してあるべきだと私は思います。

私は一人の開発者として、サンプルのソースコードがいい加減であるために、それを修正するための時間を取られるのは非常に腹立たしいですし、そして、他の開発者の時間も同様に、無駄に損失させてはならないという考えを持っています。

将棋所も、USIプロトコルも思考エンジンの開発者の手助け(?)をするために生み出されたものだと私は理解していますが(そして将棋所というソフトウェアによって思考エンジン開発の時間はずいぶん短縮化されていますが)、しかし、それならコピペされるであろうサンプルのソースコード(Lesserkai)によって、他の開発者の時間を損失させるのがいけないことだと何故わかってもらえないのでしょうか。そのへんが不思議でなりません。

LS3600LS3600 2011/12/22 00:16 > 一度改行を入れてから日本語を書くといいようです。あとで「エンジン作成時の注意点」に追加しておきます。

これについては、素晴らしい情報ですね。本当に助かります。
将棋所のデバッグウィンドウに日本語表示が出来れば、開発効率が格段に上がります。

> プロトコルを設計しないのか不思議に思います。

まず、全くの独自プロトコルを設計する意味はあまりないと思います。

少なくとも、私もUSIプロトコル対応のためにsfenの読み書きするサブルーチンはすでに書いており、USIプロトコルをベースにしたほうがそれらのサブルーチンを使いまわせるので少ないステップ数で実装できるからです。

USIプロトコル自体を改良したい点はさまざまありますし、実際、私はクラスター化のためにUSIプロトコルをいくつか拡張したりはしています。これはGPS将棋やボンクラーズでも事情は同じだと思います。実はUSIプロトコルそのままですといくつかの点において、クラスター化のときに困るのです。

GPS将棋の金子さんが以下のようなtweetをされており、この2つ目が私が言っているのと同じ意図だと思われます。

https://twitter.com/#!/tkaneko/status/148609913449488384
> tkaneko @takodori USIの登場は開発者に選択肢が増えたというメリットが大きいと考えています。後は、バージョン記号をつけて改定してゆけると良いと思うのですが、現状は私家版の改訂案ばかりというのがきっと不便の一因ですね。

https://twitter.com/#!/tkaneko/status/148612136602578944
> tkaneko usiを改定するなら優先度の高い作業の一つは、positionやbestmoveにidをつけるオプションを用意して、対応関係を明確にできるようにすることかな。(囲碁のgtpにはある)

https://twitter.com/#!/tkaneko/status/148760227913793536
> tkaneko @takodori 知る限りでは合意形成努力は特に成されていないと思います。 (ponderが実状と合わない等は多数派だと思いますが、次の具体案としては)


それで私がコンピューター将棋に新しいプロトコルを策定しても、そのプロトコルに思考エンジンを対応させるための負担がそれぞれ思考エンジンの開発者にのしかかってくるのであれば、他の思考エンジンの開発者の足を引っ張っているだけになってしまいます。そういうのはよろしくないというのが私の考えなので、結局のところ、

1) USIプロトコルを思考エンジンの開発者間で合意形成努力をした上で拡張する
2) その拡張したUSIプロトコルに対応する将棋所レベルのホストプログラムを実装する

というのがベストだと私は考えています。1)だけやっても2)がなくてはどうにもなりませんので、私は2)をやってくれる人が現れるのを待っています。(merom686さんとか、aki.さんだとか..)

将棋所がオープンソースで公開されていれば、私が何らかの方法で1)で合意を形成した上で、その拡張仕様をそのオープンソースになっている将棋所のソースコードに手を加えてコミットすることはお約束できるのですが、将棋所をオープンソースにする予定はありませんよね?

それで、まあ、結局、私が自分で将棋所みたいなソフトウェアを作るかって言う話にはなるのですが、その時間があるなら思考エンジンの開発に少しでも時間を費やしたいんですよね。それで、オープンソースでUSIプロトコル対応のホストプログラムを作ってくれる救世主が現れるのを待っているような状況なのです。


どうか救世主が現れますように。サンタさんがクリスマスプレゼントを持って現れますように。サンタ様と天の神様にお祈り申し上げます。