Hatena::ブログ(Diary)

やねうらお−ノーゲーム・ノーライフ このページをアンテナに追加 RSSフィード

GT-Rの買取ならここですわ。どこよりも高く買取ってもらえるはず。お勧め!GT-R 買取
電王戦出場記念! 書籍化されたで! 監修したで!(`ω´) 絶版なってしもた Kindle版で復活!! 記事書いたで!
解析魔法少女美咲ちゃん マジカル・オープン!

YaneuLabs / やねうら王公式 / やねうらおにメール / twitter / プロフィール

 | 

2013-10-28 電王戦 --- 将棋電王トーナメント --- やねうら王特設ページその2

[] 電王戦 --- 将棋電王トーナメント --- やねうら王特設ページその2  電王戦 --- 将棋電王トーナメント --- やねうら王特設ページその2を含むブックマーク  電王戦 --- 将棋電王トーナメント --- やねうら王特設ページその2のブックマークコメント


■ 2013/10/28 2:20 前記事が長文になりすぎたので新しいページを開設。


前記事)

電王戦 --- 将棋電王トーナメント --- やねうら王特設ページ

http://d.hatena.ne.jp/yaneurao/20131013#p1


前記事の内容を三行で要約。


・やね裏定跡、やね裏学習メソッドI,IIの実装完了。評価関数パラメーターの収束、祈祷中。

・持ち時間制御などあと3000行ぐらい当日までに書かなくてはならないが、すべてが完璧に書けて、かつバグなしに一発で動くよう祈祷中。

・探索部の根が深そうなバグを修正し、さらに探索パラメーターの調整をしないといけないが、手作業によるチューンによって一発で神調整になるよう祈祷中。


って、祈祷ばっかりやがな!ヽ(`Д´)ノ

皆様もコメント欄でご祈祷のほう、よろしくお願い致します。


なお、電王戦トーナメントの最終局直前までVisual Studioを立ち上げ、やねうら王の開発を続けたいと思います。(気力が残っていれば)


■ 2013/10/28 12:10 評価関数はどうあるべきか


Q) 評価関数のそれぞれのパラメタの値は、ボナンザと似たような感じになるもんなんでしょうか?

A)

まず一般論としてBonanzaと同じ三駒関係であっても、ボナンザメソッドで学習させる棋譜によってそれぞれのパラメーターの値はずいぶん異なってきます。


評価関数の目標は、自分に有利な局面をプラスの値、自分に不利な局面をマイナスの値が出力されることなので、そういう意味では、究極的にはどのソフトでも出力としての評価値は同じぐらいの値に落ち着くべきなのですが、そうはなっていないのが実状です。


その原因としまして、評価関数の分解能(汎化能力)によってはそれが達成できなかったり(似た問題に「XOR演算は線形分離できないのでパーセプトロンでは学習が難しい」がありますが、それと同様です)、あるいは機械学習アルゴリズムによってはうまい値に収束しなかったり、サンプルとすべき棋譜が足りていないので特定のパラメーターが学習できずに0のままだったり、サンプルとすべき棋譜に誤り(悪手)が含まれていたり…。


ただ、駒得のみの評価関数であっても深さ∞まで探索すれば、現在の局面に対して正確に勝ち負け(と引き分け)が判定できることからして、評価関数が多少粗雑であっても探索を深くすればある程度優劣は正しく判定できるということがわかります。つまり、探索を深くすれば(探索結果としての)評価値は似たような値(少なくとも符号ぐらいは一致する)ようになります。このへんがなかなか神秘的なところですね。


■ 2013/10/28 2:55 ハッシュ衝突を回避


64bitハッシュでも持ち時間が長く、局面数をたくさん探索するとハッシュ値の衝突は起こりうるわけで、今日はそれが気になってそのときにエラーで落ちないようにコードを追加したけど、今度はその追加したコードバグってないかだとかの検証が大変。


こんなコード追加しても強くなるどころか遅くなって弱くなるだけなのに…。しくしく。


■ 2013/10/28 3:10 思考時間制御


Bonanzaの思考時間制御ってどうなってたかなーと思って、ソースコードを読み返したら、大雑把に言えば、今回の思考時間 = 残り時間/35 みたいな式になっていた。つまり、時間は1/35ずつ減るので、時間消費量は、(34/35)^N みたいな指数関数的な減衰をする。

この関数半減期(?)は 1/2 = (34/35)^Nの両辺logをとって、N = log(1/2) / log(34/35) ≒ 23.9。24手ほど自分が指すと思考時間が残り半分になっている計算だ。(実際は、思考を早めに切り上げたりすることがあるので半減するのにもう少し余裕がある)


終盤の時間が徐々に減っていくので私はこの方式は、どうかと思うのだけど、Bonanzaがやってるぐらいなのでそんなに悪くないのだろう。


Stockfishは、時間配分ソースコードがC++templateで書かれていて読み解く時間がないのだが、時間延長の処理としては反復深化でbestmoveが更新された回数を局面の不安定性として捉え、今回の思考時間 = (その回数×今回の指し手のための時間 / 1.4) だけ時間を延長する、みたいな方法が取られている。


このへん、なかなか興味深い。


■ 2013/10/29 3:15 計算資源の貸し出しについて


いまから思考時間制御のコードを書いて、自己対戦をしてパラメータの調整などをしないといけない。ところが自己対戦200戦もするとなると、2分切れ負けでも相当時間がかかる。そもそも2分切れ負けだと後半、ほとんどの指し手が1秒なので実験にならない。


そこでテスト用のマシンが複数必要になる。このマシンを本来は不特定多数からお借りすることが出来ればいいのだが、インターネットが普及して20年近く経とうというのに、いまだ仮想化された計算資源を、投げ銭をするぐらいの手軽さで他人に貸し出すことはできない。だから、いくらこのブログにそこそこのPVがあり、日々の訪問者が何千人いようとも計算資源の貸し出しという観点においては全くの無意味である


本来、その程度のことはOSがサポートすべきなのである。OSがこういう機能をサポートしないのは、怠惰であり、科学技術の発展を阻害しているわけである


OSがサポートしてくれないなら、ブラウザに頼るほかない。仮想環境自体はGoogle Native Client程度のもので良いのだ。問題は、それをクリック一つで他人に貸し出せなければならないということだ。(貸し出すからには、相手が自分のPCのリソースをどれだけ使用しているのかだとか、いつ使用していたのかだとか、そういう統計情報の表示が必須である。)


ブラウザを作っている人たちは、どうかご一考いただきたい。

OSレベルでサポートされない以上、あなたたちこそが最後の砦なのであるから。


■ 2013/10/29 5:20 思考時間制御が一応書けた


なんか適当に書いたのにそこそこうまく動いている(気がします)

if (byoyomi == 0)
{
	// 秒読み時間が設定されていない(無し)のときの戦略

	myOptTime = remain / 35 ; // 35で割って、その1/3を目安にiterationする
	myMaxTime = remain / 25 ; // これ以上使うとさすがにやばいだろ..
	myMinTime = 0; // どうせ端数は繰り上げる

} else {

	// 秒読み時間が設定されているときの戦略

	if (remain >= byoyomi * 20)
	{
		// 残り時間が秒読み時間に対して極めて長い。(そもそもそんな短い秒読みとかありえん気がするが…)

		myOptTime = remain / 35 + byoyomi ; // 35で割って、秒読みも加味してその1/3を目安にiterationする
		myMaxTime = remain / 25 + byoyomi ; // これ以上使うとさすがにやばいだろというライン
		myMinTime = byoyomi ; // どうせ端数は繰り上げる。
	}
	else
	{
		// 残り時間少なくなってきたので、秒読み時間を使うこと前提の時間配分に変更しよう。
		myOptTime = remain / 10 + byoyomi ; // 10で割って、その1/3を目安にiterationする
		myMaxTime = remain / 5 + byoyomi ; // これ以上使うとさすがにやばいだろ..
		myMinTime = byoyomi ; // どうせ端数は繰り上げる
	}
}

あとStockfish風に(さっきソースコード見て知ったばかりなのに!)、iteration中にbest moveが変化した回数に応じて探索時間の加算をしてます。


myOptTime(optimum timeの意味)を基準に考え、1回のiterationごとに経過時間がこの時間の1/3を超えていたら(PonanzaのC#のソースコードがそうなっていたから!)、探索を終了します。


しかし、終了するときに秒読み時間が余っていたらもったいないので、myMinTimeの時間分だけは是が非でも思考するという風に作ってあります。


また、探索時間延長時にmyMaxTimeを超えないようにします。これを超えると時間切れの可能性が出てくるので。


iteration部は、aspiration searchになっていて、aspiration中のbest moveの取り出しについては置換表などの関係から結果が安定しない(YSSの山下さんがそんなことを言っていたと伝え聞き)らしいのですが、やねうら王ではaspiration searchでもそこから無理矢理、結果を取り出しています。一応、自己対戦の勝率からすると、その部分はきちんと効果が出ているようです。(たぶん)


aspiration searchの中の思考結果の取り出しについてはいろいろ書きたいことがあるのですが、ちょっと専門的かつ長くなるので、これについてはもう少しよく考えてから論文か本にでも書きます。(一言で言うと、Fail-Highしたスコアがそのノードの真のスコアの下界(下限)だと仮定できるなら、例えば探索開始局面の最後の手だけFail-Highしたなら、aspiration searchの探索窓を広げての再探索をしなくてもいいだとか、そういう結論が得られます。ところが…みたいな話です。)


■ 2013/10/29 5:45 探索がおかしい原因が判明


原因の一つがなんとなくわかった。良かれと思って3年ほど前に高速化のためにやったことが全くの裏目に出ているであろうことがわかった。さっき寝てたら、突然夢のなかでわかって、飛び起きた。


バグというよりは、設計上のミスというか、将棋というゲーム木の探索の性質をよく理解していなかったというか、そういうことに起因する問題であり、プログラム自体は私の意図通りに動いていたのだと思う。


これをなおすにはソースコードを大量に書き換えないといけない。時間がもう残されていない。そんなに大量のソースコードバグなしで一発で書き換えられる自信がない。私は目が超悪くなってから、typoが絶えなくて、ロジックのミスがなくとも何らかの打ち間違いなどによるエラーが起きる可能性が高い。こんな状況でやるべきことではない。


この部分をなおせば、おそらくBonanzaには勝ち越すはずなんだが(他にも原因がない限り)…いまからではその書き換えは間に合わないだろう…本当…残念でならない。iOS版のテイルズオブハーツRという超大作ゲームをこんな時期に出してきやがったナムコバンダイが恨めしい。なんて面白いゲームを作りやがるんだ、くそ〜!


■ 2013/10/29 13:25 best moveの変化


Stockfish風にbest moveが変化した回数に比例させて思考時間を延長するコードにしたのだが、以前のバージョンと対戦させると4:6ぐらいで負け越し。(時間がないのであまり正確な計測ではない)


best moveが変化すると言っても(反復深化の)iterationの直近で変化するのと、最初のほうのiterationで変化するのとでは大きく意味が異なり、直近で変化した場合、それはそれなりに大きく評価しなければならないと思う。


本当はこのへん、統計をとってどうこうすべきだが、そんな時間もないし、

	best_move_changed += iteration_depth/3;

みたいな適当なコードを書いておいた。直近のほうがbest moveの変化に対する意義が大きいと言う意味でだ。

5分ぐらいの持ち時間ならば、これでうまく指せているようなのだが、これが大会の持ち時間になったときに本当に大丈夫かどうかはわからん…。ただただお祈りするのみだ。


■ 2013/10/29 13:40 強さの判定には標準的な定跡が必要


やね裏定跡などという変な必勝定跡(?)を搭載してしまったので、自己対戦させても序盤で形勢に差がついていて、強いのか弱いのすらわからない。かと言って定跡をオフにすると似た進行ばかりになり対戦の意義が薄れてしまう。


こういう事態を避けるために、強さを計測するための標準的な定跡が必要不可欠である

(あかん。そんなこといまさらそんなこと言ってももう間に合わん…。)


■ 2013/10/29 15:15 CSA拡張プロトコルにおける秒読みの意味


いま気づいたんですが、

消費時間の計測は、デフォルトで、いわゆるチェスクロック方式。また、byoyomi_timeが1以上であれば、total_timeで指定された持時間を消費し尽くしたのちに、秒読みとなる。

ただし、byoyomi_timeが060のときに限り、1分単位のいわゆるストップウォッチ計測。すなわち、消費時間は1分単位で切り捨てられたのち、持時間から減らされる。1分未満に指せば持時間は減らない。持時間がゼロになった時点で時間切れ負け。

http://shogi-server.sourceforge.jp/protocol.html

プロ棋士との対局時の5時間+1手1分の1分はただの秒読みじゃないんですね、これ。ということは、考慮時間が残っているときに、4分0秒みたいな時間の使い方はもったいなくて、4分59秒みたいに使わないといけないという…。知らなかった…。その処理、いまから書きます。


2013/11/16 追記  上のは私が誤解してました。「060」のときだけストップウォッチ計測。「60」のときはチェスクロック計測。そして今回はチェスクロック計測。つまり、今回のために上のような処理は不要でした。


■ 2013/10/29 15:30 秒読み60秒に対応


前回の電王戦みたく代理の人が指すなら50秒目ぐらいまでに指し手を返すべき?

	if (!listener->isInfinite && listener->byoyomiTime == 60*1000)
	{
		// 秒読みが60秒に設定されていると、CSA拡張プロトコルでは、ストップウォッチ計測らしい

		// 1分で切り捨てて50秒足しておくか。これだけは使わないともったいない的な意味で
		myMinTime = ((myMinTime-1)/60000)*60000 + 50000;
		// あと、maxはギリギリの値だと怖いので、maxもX分50秒にしておく
		myMaxTime = ((myMaxTime-1)/60000)*60000 + 50000;

		// 1引いてあるのは持ち時間なしになるとmyMinTime == byoyomiTimeになるので1引いていないと1分50秒になるから。

	}

しかし、これいまから5時間の1手1分なんて持ち時間での動作テストできないので、うまく動くかは知らない…。

ロジックおかしくてうまく動かないなら、そのときは思考エンジン設定で秒読み50秒とかに設定して、普通に指せばいいや…。


■ 2013/10/29 15:35 CSAプロトコルの秒読み


予選が15分 + 1手10秒なんですが、CSAプロトコルは秒の端数切捨てて(また1秒未満は1秒として計測)なので、例えば0.1秒も1.8秒も1秒と計測され、また秒読み10秒だと10.9秒まで使えることになるはずなんですが…これ正しいんですかね。一応、そのつもりでプログラムを書いてるんですが、さすがに予選リーグで秒読みで切れ負けしたら格好悪いですよねぇ…。


いまからドワンゴテストサーバーで試してきます(´・ω・`)


■ 2013/10/29 15:45 秒読みありで残り時間が少ないとき


残り時間15秒、秒読み10秒みたいなとき、もう残り時間を使いきって25秒考えたほうが得ではないかと思い、次のコードを追加。

	// こんな端数の残り時間は、使いきっちまいなよ
	if (remain <= byoyomi*2)
	{
		myOptTime = remain + byoyomi;
		myMaxTime = remain + byoyomi;
		myMinTime = remain + byoyomi;
	}

■ 2013/10/29 16:50 ドワンゴサーバーでは秒読みテストにならない件


対戦相手に放置してあるサンプルプログラムが弱すぎて、秒読みになる前に自爆するため秒読みのテストにならないようです。


CSA拡張プロトコルなのでwhoコマンドで対戦相手を探して選べるらしいので自分でもう一台のPCから参加してそいつとマッチングさせられればいいのですが、将棋所でコマンド送信はたぶん出来ないと思うのでよくわかりません。このへん時間があれば調べるのですが、それを調べている時間も惜しいという…。


この分では当日朝早く行くか、前日参加でテストしないといけないようです。そう言えば前日のテスト日なのですが書類に「希望者のみ」と書いてあったのですが、事前表明要るのでしょうか…。


まあ、当日の朝テストします。10.9秒まで思考させてタイムアウトになるようなら思考エンジンコンパイルしなおさなくとも秒読み設定を9秒に変更すればいいわけですし。


■ 2013/10/29 18:05 Bonanza6の時間の使い方が下手すぎる件


Bonanza6なのだが、いま対戦テストしているのだけど、電王戦トーナメント予選時の設定(持ち時間15分・秒読み10秒設定)だと60手目ぐらいで持ち時間を使い切る。いくらなんでも早すぎる気がする。


ただ、そこで形勢が大差になっていると残り1手に10秒もあればコンピューターはなかなか間違えないのでこれはこれで結構嫌なのだが。


ちなみに、やねうら王は上記設定においては100手目付近に時間を使い切るように調整した。形勢互角ぐらいで100手目ぐらいまでくれば8割ぐらい勝てると思うのだけど、100手目までに大差になっていると挽回できない。そんな感じ。


あと、Bonanza6だと秒読み10秒あるにも関わらずone reply(1手しか応手がない場合)即指しする。ここはきちんと10秒間、考えたほうが得だと思うのだが。


やねうら王は即詰みを見つけたとき(相手からの即詰みも含む)以外はone replyでも秒読み時間は使い切るようにしてある。


BonanzaはBonanza6からは修正されているとは思うのだけど、思考時間まわり、どうなんだろう…。電王戦トーナメント予選の秒読み10秒という設定はそれ相応の対策をしていないと…。


■ 2013/10/29 19:53 思考エンジン設定


拡張CSAプロトコルの秒読み60秒に対応させ、この設定のときに何秒まで使うかというのを将棋所で設定できるようにした。


f:id:yaneurao:20131029195405p:image


こういう設定を保存したり、保存したものを復元したり、これに関連してドキュメントを更新したりで凄く時間が取られる。そもそもこんな設定、電王戦トーナメントで上位5位に残らないと何の意味もないのに…。


■ 2013/10/29 20:00 思考時間の制御はもういいや


15分+秒読み10秒の連続対局だと時間がかかりすぎるので、その1/3の時間(5分+秒読み3秒)でテスト。そこそこうまく使ってくれているようなので、もうこれでいいや。


電王戦トーナメントの本戦は2時間切れ負けらしいのだけど、このテストも1回ぐらいは2時間の持ち時間でやっておくべきのような気がするのだが、そのマシンがない。本戦でオーバーフローとかで誤動作して落ちたりしてな…。


■ 2013/10/29 22:00 Bonanza定跡だとハマる


Bonanzaと対戦させているとBonanzaに登録されている定跡はそんなに多くないせいか、比較的簡単に前回と同じ局面になる。


今回の電王戦トーナメントと同じスペックマシンが私の手元にないので同じ局面になったところでそのあとのBonanzaの指し手はわからない。(しかも大会に出てくるのがBonanza 6そのままということもないので、実際は同じ局面になるかもわからないが。)


大会に出場するバージョンソースコードを一式公開しているようなソフトの場合、比較的簡単にやね裏学習メソッドの餌食になる。もっとも、事前にシミュレーションするためには、大会と同じスペックマシンが必要だ。


今回の電王戦のように大会が統一ハードでなされるのであれば、お金さえあれば同じハードを用意できるわけで、出場ソフトは、事前に大会バージョンソースコードを公開しない(GitHubで公開したまま開発するとか禁止!)、(定跡ファイルなどの)手の内を明かさない、みたいな対策が必須となってくる。…気がする。


■ 2013/10/30 9:40 思考時間がオーバーする問題


秒読みが10秒なので9.92秒まで使うようにしていたのだが、やね裏学習メソッドI(局中に指し手のDBへの記録)をONにしていると将棋所で思考時間11秒と記録されてしまう。明らかにタイムオーバーになっている。


思考開始時間というのは、USIプロトコルによるgoコマンドが来てから計測しているのだが、サーバー的には、positionコマンドで局面を送った時点で計測開始していたりしないだろうか…。まあ、それについては誤差だと思うのだが、考えてみるといろんなオーバーヘッドがある。


サーバークライアント間の通信時間や、将棋所と思考エンジンとのやりとりの時間はもちろんのこと、メインスレッドとサブスレッドとのやりとりの時間もある。best moveの報告用のスレッドをSleep(0)とかSleep(1)とかで待機させておくと思考部のCPU資源を少し食うのでSleep(10)とかで待機させているのだが、これだと少なくとも10msの遅延が生じる。


プログラムに多少詳しい人ならば「Sleep使わずにシグナルを使え」と言うだろうけど、Sleep(0)のほうがシグナルを使うよりレスポンスがはるかにいい。*1 このような理由で(?)Bonanzaは全体的にSleepで書いてあり、やねうら王もそれに倣い全体的にSleepで書いてしまった。いまから書き直すのは結構の分量になるので、それは避けたい。(電王戦終わってから考える)


その他、一番大きな理由として、SQLite3がCPU資源を消費するということだ。SQLite3はスレッドセーフであり、非同期処理をしているようなのだが、それはすなわちスレッドが別にどこかに作られているということで、これにより、思考エンジンで使用している他のスレッドの動作が緩慢になる。間接的に影響を受ける。


それより増して問題になるのは、SQLite3がデータベースの書き出しをファイルに行なうとき…いまどき、DMA転送になっているのだが、バーストモードだとCPUから制御を奪うのでCPUの動作に支障を及ぼす気がする。(よく知らん)


ともかく、SQLite3がディスクに書き出すときにサブスレッドの動作に遅延が発生しており、これがせいで、将棋所で秒読み10秒設定なのに11秒と計測されてしまうのである将棋所でそう計測されるぐらいだから、大会のようにサーバーと接続している場合、間違いなくアウトである


そこでこの9.92秒の秒未満の0.92秒(920[ms])という数字を思考エンジンの設定ダイアログで変更できるようにした。ここまでが昨日の話である


いま問題なのは、この920という数字をいくらにすべきかということだ。SQLite3はDBファイルが大きくなってくると読み書きに時間がかかるようになる。正直、読めない意味がある。下手すると、インデックスの再構築なんかで瞬間的に大きな負荷がかかる可能性もある。


電王戦トーナメントの本戦は2時間切れ負けなので、秒読みの問題はないのでこのへんは無視できるのだが、予選のほうは、秒読みなのでこの問題が避けられない。時間切れで、下位のソフトに負けでもしたらもはや本戦出場が危ぶまれる。


そこで下位のソフトと対局するときは、将棋所の対局設定として秒読みを10秒ではなく9秒に設定しておくだとか、局中の学習をオフにしておくだとか、そういった対策が考えられる。あまり真っ当なやり方ではないが、大会マシン性能(ディスクまわりも含めて)が予想できないので、緊急回避である


このように、対戦相手に応じて対局設定を変更しないといけないわけであるが、対戦相手確定後に対局設定を変更できるのかどうかは知らない。駄目なら秒読み9秒のまま運用するしかないが…。


■ 2013/10/30 10:00 10年後のコンピューター将棋について


前のバージョンの改良が正しく行えているかを自己対戦して勝率で計測するのですが、これが対局時間設定が短いとかなりいい加減な感じです。時間を長くすると、検証し終わるのに時間がかかりすぎますし、それで検証しても、なんというか、定跡を抜けた局面ですでに形勢に優劣が多少ついているので、そのまま押し切ってしまうことが結構あります。


コンピューター将棋人類未踏の領域に踏み込もうとしているからなのですが、これが10年後とかですと、さらにコンピューター将棋の精度(中盤〜終盤)が上がっており、滅多に逆転を許さないようになっているでしょう。そうすると、定跡選択だけで勝敗が決まってしまう(100%決まらなくとも、勝率には大きな影響を及ぼす)ようになることは想像に難くありません。


そのときになって、やね裏定跡や、やね裏学習メソッドI,IIの重要性が見直される…といいですなぁ…(遠い目)



■ 2013/10/30 10:30 評価関数が収束?


まだ以前のバージョンと対局させているところなのでよくわかりませんが、評価値がおかしい値にはなっていないことだけは確認できました。良かった良かった。これでとりあえず電王戦トーナメントに出場できますね。


■ 2013/10/30 10:40 千日手問題が発覚


やねうら王には千日手を回避する機能があり、探索部で以下のような処理になっています。

つまり、千日手局面を龍の価値分(龍損の半分)の評価値をつけておけば、互角の局面とかなら、千日手手順を自動的に回避するという、そういうhackです。

	// 同一局面4回での千日手。
	// このチェックをしておかないと下手な探索延長をすると繰り返しで終わらなくなる。
	case four_fold_rep:

		// 自分の手番ならわずかに不利という扱いにしておこう。
		// そうすればこの手順は回避するはずだ。
		// 置換表上、整合性が取れずにまずいかどうかは知らん…。
		// そもそもscore_inferiorだってこれに近い扱いだし…。
		if (TURN == tree->root_turn)
		{
		// 龍の価値分とみなす。
		// ここから逆転勝ちできる可能性は1/2よりは小さいだろうから引き分けで1/2の勝ちが拾えるなら
		// それは得だろう。
			if (Search::avoid_sennichite)
				best_alpha.value = -DDragon;
			else
				best_alpha.value = score_draw;

		} else {

			// 相手による千日手も回避したいなら、このスコアを相手有利のスコアにしておくべき。
			if (Search::avoid_sennichite)
				best_alpha.value = +DDragon; // 相手から見て龍の価値分ぐらいの得だとしておこう。
			else
				best_alpha.value = score_draw;
		}
		return best_alpha;

ところが、やね裏学習メソッドI(局中に自分の指した手を記憶しておく)をONにしていると、自分の指した手を覚えているので、2回目以降その局面に遭遇するとそれが千日手手順であってもそこに踏み込んでしまいます。


千日手になって下位のソフトと引き分けになることほど馬鹿らしいことはないので、これをなんとかして回避する必要があります。


そこで、指す前に千日手になる手かどうかを判定し、千日手になるのであれば、再探索するようなコードが追加で必要となります。これはこれで結構の改造ですが、いまから…やります…。


こんな改造してエンバグしないといいんだがなぁ…。(´・ω・`)


■ 2013/10/30 15:25 ホテルの予約完了


ホテルの予約忘れてたのでいまやりました。そのあと仕事電話がかかってきて、応対してたらこんな時間に…。

とりあえずいまから千日手回避のコード追加します。


■ 2013/10/30 15:30 棋譜からの学習は過学習の塊


棋譜からの学習、実戦で出てこない(学習に使っている棋譜に出てこない)形は評価できず特徴因子の値が0になる。(実際は0ではないけど0相当である)


また、実際は無関係なのに関連付けて学習してしまう。一言で言うと過学習である。手でチューンしたら絶対こんな値にならないのに、という値になっている因子がたくさんある。これらを如何にして是正するかが、ボナンザメソッドの課題である。だからこそ、他の開発者は、Bonanzaパラメーターを可視化したりしていかにしてパラメーターを是正するか考えているのである。(例 : bona6.0の3駒評価の可視化 http://d.hatena.ne.jp/suzume_r/20130904 )


私は過学習は嫌いなので、棋譜との指し手の一致度を上げるより、過学習を抑えるほうに力を入れたほうがいいのではないかという派である。これに対して、棋譜との指し手が一致しているほうがいいという派の人たちも結構見かける。(もしかしたらほとんどの開発者が後者かも知れない)


「一見無関係に思える、端歩と突き捨てとの関係も、その戦型においては意味のあることだから」うんぬん。


それはそれで一理あるのだが、探索が深くなってきたときに副作用を及ぼしかねない部分はバッサリ切り捨てていくほうが将来的なことを考えると正しいアプローチだと私は信じている。この先、10年後ぐらいにPCのスペックが格段に上がったときにこのことが実証される。(といいなぁ…)


■ 2013/10/30 18:00 千日手回避コードが書けた


上で書いた、千日手、探索の途中で中途半端な評価値をつけるアイデアはあまりよろしくなく(置換表上の整合性が取れなくなる)、うまく機能しなかった。置換表の書き出しに対してもうひと工夫する必要がある。


ここを下手にいまいじりたくないので、千日手は100%回避するようにした。千日手を無理矢理回避した結果、不利な局面になって自滅しても、それはそれで仕方ない。


ただ、千日手になった局面を自分の負けとして評価値を設定すると、千日手になりそうな仕掛けは事前に見送るという効果もあるので、早めに不要な探索が打ちきれて良いような気も少しする。


■ 2013/10/30 18:10 旧バージョンと対戦させると…


改良しておかしバグを仕込んでいないかを検証するために以前のバージョンと対戦させてテストするわけだが、以前のバージョンは秒読みいっぱいまで読む戦略だったし、局中の学習定跡も未実装だったのでDBへのアクセスもしていなかった。それゆえ、0.5秒分ほど得なんだ。


3分切れ負けにおける1手0.5秒ハンデの重みは相当で、たぶんこれのせいで、負け越す。たぶんこれのせいだよ。バグのせいじゃないよ。これのせい、これのせい。


などと呪文のように唱えながら、改良するごとに勝率が下がってくるのを見ていると心が折れそう。



■ 2013/10/30 18:40 テイルズオブハーツRをやりすぎてしまった…


コンピューター将棋の開発はマシンが3台ぐらいしかないと、少しコード書いては1時間テストして、みたいな開発サイクルなので、結構空き時間が退屈である。本当は1日にちょっとコードを書いて寝ている間にテストして、みたいな開発サイクルが一番効率的なのだろう。


そんなわけで大量に空き時間が出来るわけであるが、私の場合、その間に仕事を他の片付けたり、ブログを更新したり、テイルズをやったりするわけである。気づいたらテイルズ、60時間近くやっていた…。いま二周目だが、フルコンプ(?)まであと50時間ぐらいかかりそう。さすがに電王戦の開催時間にはやらないが。(待機時間にはやるかも知れん)


ちなみに、このテイルズオブハーツRと言うゲーム、「デスピル病」という「スピリア」の病(やまい)がゲームの主題となっている。このゲームで「スピリア」とは「精神」のことらしく、それを病んでしまうわけだ。要するに精神の病である精神病とは違うのかも知れないが、「デスピル病」を「精神病」(あるいは具体的な病名)と頭のなかで読み替えながらゲームを進めるとなかなか味わい深いものがある。


f:id:yaneurao:20131030184337j:image:w400


例えば、ヒロインのお母さんが主人公たちを殺そうとしたときも、主人公たちはお母さんを庇って、「デスピル病なんでしょ?だから仕方なかったんでしょ?」みたいに言うわけだ。でもお母さんは結局はデスピル病ではなかったのだ。そのことを知って愕然とする主人公たちに向けた二千年生きている女の子、リチアさん(右後ろの緑の髪の少女)の言葉。


f:id:yaneurao:20131030184336j:image:w400


なんか味わい深くないですか?


人の精神は精神疾患でなくても時として暴走し、恐ろしい振る舞いをしてしまうのです。(どーん)


なんでもかんでもデスピル病であるかデスピル病でないかということを基準にしか考えられない主人公たちへの、あるいはゲームテーマ自体への痛烈な批判となっております。なかなか味わい深いものがありますね。


■ 2013/10/30 20:00 千日手回避のコード


千日手回避のために千日手局面になったところで、score_foul(このへん、定数の意味Bonanzaと同じ)を返すようにしたら、千日手に遭遇したら指し手を返さないようになった。無論、タイムアップまでまっしぐらである。さっき、対局テストしてたらこの現象になって、冷や汗が出た。ここは、score_inferiorを返さないといけない。


なんか怖くなってきたのでもう改造するのはやめて、今日・明日は動作テストに徹することにします。


皆様、ご祈祷ありがとうございました…。


■ 2013/10/30 20:10 千日手を回避して本当にいいのか?


将棋は意外と千日手になる手順が出てくるゲームであって、馬を作って、飛車を責めるような手順ですぐに千日手になる。その局面を回避しようと思うとそのような手を指させないようにしないといけなくなり、特定の指し手がすべて封じられてしまう。


いわばハンデ戦のようになって、そういう戦い方をするとすこぶる不利なのではなかろうか。


Bonanzaは、千日手による引き分けはscore_draw(±0)として扱ってあり、回避する試みすら感じられない。そのため、千日手になる手順であろうが平気で踏み込んでくる。こっちは千日手にさせないようにいくつかの指し手を封じられているのにまったくたまったもんじゃない。


どう考えてもこちらの戦い方は損である


■ 2013/10/30 20:20 時間計測の件


大会ルールをいま読んだところ、CSAルールのようで、このルールでは秒未満は切り捨てで正しいようです。

(消費時間)

第 17 条

1 手毎に、実際の消費時間を計測した上で秒未満を切り捨てたものを 1 手毎の消費時間とする。

ただし、ある手の消費時間が 1 秒未満の場合、その手の消費時間は 1 秒とする。

すなわち、計測された消費時間を x 秒、このルール上の消費時間を s 秒と表わすとき、x<2 であれば、s=1 とする。

また n を 2 以上の自然数とするとき、n<=x<n+1 であれば、s=n とする。

累積消費時間は、1 手毎の消費時間を累積したものとする。

将棋所はCSAルールに対応していないので、将棋所の指し手ごとの秒数としては1秒多い秒数が表示されるんですかね。


ということで将棋所では5分+秒読み10秒ではなく、5分+秒読み11秒に設定して対局すると良いということでしょうか。


こんなギリギリコンマ何秒を稼ぐためにタイムアップと隣り合わせなのは気が進まないですけど…。


■ 2013/10/30 20:30 やね裏学習メソッドIIに関するアイデア


コメント欄でご指摘いただいたのですが、やね裏学習メソッドIIで検討するときに終局図からさかのぼって検討したほうがいいのではないかという点についてお答えします。


私の実装も逆順で検討するようになっています。そのほうが少し得だと思います。詰みが絡むような時には、詰みの値が置換表に書かれているわけですから。


また実装としてはDBに未検討の局面についてqueryかけるときに「手数(初手から何手目か)」でORDER BYでDESC(降順)にすればいいだけですのでこの実装で良ければすこぶる簡単ですよね。


■ 2013/10/30 20:45 やね裏定跡は嫌な予感がする


やね裏定跡による先手勝率は後手のそれよりかなりいい。何故かと言うとやね裏定跡同士だと先手のほうが有利になる変化が多いからだ。


そもそも将棋において後手は1手分損しているはずであり、損しているからには、評価値が少し悪くなって当たり前なわけである。それなのに互角以上だと判断していたソフトは、(たまたま試合には勝てたのかも知れないが)形勢判断がおかしソフトなのかも知れない。


そういう意味では、やね裏定跡の後手のほうは、結構、損な分かれになっている局面がある。特に嫌なのが先手にストレートに穴熊に組ませる変化だ。か、、勘弁してくれ。この定跡、手で修正してやろうかとちょっと思わないではない。しかしそのためには定跡編集ツールが必要だ。(そのうち作ろう…)



■ 2013/10/30 20:50 置換表のサイズはいくらがベストか?


置換表のサイズはいくらがベストか悩ましい。大きいほうが良さそうだが、大きいとCPU cacheのhit率も下がるわけで、本当に大きいほうがいいかどうかはわからない。特に浅い探索であれば置換表は小さいほうが好ましいはずだ。


しかし深い探索になってくると探索ノード数が増えるので、小さい置換表だとエントリー(登録しようとする局面のデータ)が衝突しやすくなる。そうすると探索効率が低下することになる。


これらのテストをきちんとやるためには、大会用のマシンで、大会用の持ち時間で何百局も対局させるしかないわけであるが、そんなマシンもそんな時間もないので結論はわからない。他の開発者はどう設定してるんだろう…。


大容量のメモリ積んでいるからと言って、最大に近いメモリにすると、置換表のクリア等ですごい時間がかかったり、あるいは、変数のどこかが32bitになっていて4GBを超える置換表だとソフトが落ちたりして…。(笑い事ではないな)


このように置換表のサイズを決めるのも大仕事なのである。早めに行って動作テストしないと…。



■ 2013/10/30 21:15 コンピューター将棋はPGOしたほうがいいのか?


Visual StudioにはPGO(Profile Guided Optimization)という機能がある。実際に実行させて、その統計的な情報により、メモリアクセスのlatencyを隠匿するようなコードにしてくれたり、よく通るほうの条件分岐をnon-jumpにしてくれたりするのである。(たぶん)


一般的プログラムではPGOにより10%ぐらいの速度が改善することがあるのだが、コンピューター将棋ではPGOはあまり効果がないようだ。Bonanzaでも昔のBonanzaはPGOで3%ぐらい速くなったらしいのだが、いまその話が通用するかどうかすらよくわからない。


当時はICC(Intel C++ Compiler)だと数%速くなるから、最終版のコンパイルだけICCでやるという話を保木さんがされていたのだけど、それも昔の話。いまやVisual C++の最適化もそこそこマシになったのでICCと優劣はほとんどつかないのが実状だと思う。


そんなわけでPGOは今回は見送る。PGOかけて、コンパイラバグってて、大会で落ちるとかシャレにならん。Visual C++もMSDNにはVisual Studio 2013が来ているのだが、いまこのタイミングで差し替えコンパイラバグっていても嫌なので私は差し替えていない。


Visual StudioのRTMは絶対にバグだらけなので、サービスパックリリースされるまで仕事に使わない」というのが人生を賢く生き抜くためのhackである。(そんな大層なもんでもないか…)



■ 2013/10/30 22:35 今年の反省点


まだ始まってもいないのに反省もどうかと思うが、書くだけ書いておく。


いまのコンピューター将棋は(特に本番環境だと)PCスペックが高くて結構探索が深いのだ。評価関数を改良するということは、大局観を良くしているようなもので、改良すればするほど深い探索においては効果を発揮し、それは勝率として跳ね返ってくる。


ところが、短い持ち時間だと探索が浅すぎて簡単な詰みの見落としとかがあって、頓死をしょっちょう喰らうので実際のところ大局観とかほとんど関係がない。


そのため3分切れ負けでテストして勝率を調べても何の参考にもならない(いろんな局面においてバグがないかというテストにはなるが…)というのが実状なのである。今回の開発期間(1週間ほどしかなかったけど)でそれが良くわかった。


今後、大会のことを考えると、どうしても開発テストのため大会と同じぐらいのスペックマシンが何台か欲しいわけだ。


ところが、Haswellの8コア版とか来年末発売と言われているし、到底来年電王戦(開催されるのかどうかは知らないが…)には間に合わない。あと、ハイパフォーマンスマシンを何台もぶん回したときの電気代も怖い。以前開発していたとき月の電気代が6万円を突破した。読者の方は「やねさんともあろう御人がたかだか6万円ぐらいが何だ」とおっしゃるかも知れないが、6万円を笑う者は6万円に泣くのである。(なんのこっちゃ)


なんにせよ仮想化された計算資源だけ借りられなければこの先やっていけないのである


しかし、ただで計算資源だけ貸せなどと厚かましいことは言わない。


そこで無料で遊べるオンライン将棋道場の開設である

専用のソフトを使ってそこで対戦してもらい、その間、コンピューターの計算資源をお借りするわけである


あ、いや、それって将棋道場でなくても良くね?


そうだ!無料で遊べるオンラインカードバトルとかにしとこう。あ、無料とは言ってもレアガチャは1回300円な。(嘘)


なんか駄目なアイデアしか出てこない。誰か、コメント欄で素晴らしいアイデアを頼む。



■ 2013/10/30 22:50 Bonanza6に対して勝率6割のBonanzaを作る方法


一つ前の記事で時間配分を台形にする戦略について書いたが、あの台形戦略、以前のテストBonanzaをあのように持ち時間を変更すると6割ぐらい勝ち越すことがわかっていた。


持ち時間や定跡選択(narrow bookかどうか)によっても勝率が変わるので別に確定情報ではないので話半分で聞いて欲しいのだが、下手に局面の不安定度を求めて持ち時間を計算しても、その時間制御が適切でなければ結局はムラのある読みになっているわけだ。


だから、そういうムラのある読みをするぐらいなら、穴熊なら40手目から本気を出すだとか、横歩取りなら20手目から本気を出すだとか、戦型に応じて時間配分を事前に決めておいた比率分を割り当てるほうがまだ理に適っているのだろう。


そこで、自己対戦を自動で繰り返しその勝率から戦型ごとの時間配分を自動で調整するような、そういうプログラムにすると面白いと思うのだが、先ほども書いたように短い持ち時間でテストしてもあまりその時間配分はあてにならないので、短い持ち時間用にチューンしても仕方がない意味もある。


そういう意味ではなかなか悩ましい。


■ 2013/10/31 00:38 Bonanzaがhangする問題


予選トーナメントの持ち時間の1/5の時間でBonanza6と対戦させようと思ったら、Bonanza6(+ u2b)では秒読み2秒だと投了が間に合わないことがあるらしく、応答がないまま、いたずらに思考時間が過ぎている。(将棋所にはタイムアップを判定して停止させる機能がないため)


掲示板でも将棋所にタイムアップの判定機能がないと嘆いている人がいるのだが、本当、タイムアップを監視して負けにする機能(設定でON/OFFできることが望ましい)は連続対局させる上では必須である千日手になって何千手にも及ぶ泥仕合になることもあるし、今回のように思考エンジンバグっていて対局が終わらないこともあるからである


何故将棋所の作者はこんなこともわからないのか…。


安定して自動連続対局が出来ないと思考エンジン開発者は安定したテストが行えず、いたずらに時間を消費し、ひいてはコンピューター将棋の進歩が遅れるのである


■ 2013/10/31 1:00 将棋所がisreadyを二つの思考エンジンに同時に渡す問題


将棋所のisreadyの実装も首を傾げざるを得ない。それというのも、対戦する二つの思考エンジンの双方に同時にisreadyを送信しているのだ。こんなことをするとその二つの思考エンジンが同時にリソース初期化(例えば評価関数パラメータファイルから読み込むなど)すると、ディスクI/Oが奪い合いになる。


Windowsファイルシステムはこういうファイルの同時のアクセススケジューリングが下手なので、こういうところを並列化すると余計に初期化に時間がかかるようになる。それ以外に、CPU時間も相手の思考エンジンとの奪い合いになる。


isreadyで何らかの思考をさせようとしたときに(例えば局前検討や、局前のデータベース最適化など)、自分と同じタイプの思考エンジンだと(例えば自己対戦させているとしたら)同時に思考してこれまたCPUリソースの奪い合いになる。


なんでこんなところを並列化するのかと言いたくなる。実際の思考プロセスでは、片方の思考エンジンずつに思考させているわけだから、当然isreadyの初期化も片側ずつ行なうべきなのである


とまあ、思考エンジン製作者にとって、将棋所では思考エンジンの開発用途として不十分な点が多々あり、ソースコードも公開されていないので改造も出来ず、また作者は自分で思考エンジンを作っている人ではないため、思考エンジンでの必要性をいくら説いたところで無駄なのである。だから、将棋所に変わる、開発者向けのGUIを誰かが作るべきなのである


将棋所は、将棋ファンが思考エンジンダウンロードしてきてその思考エンジンで対局して遊ぶには最高のGUIなだけに、思考エンジン開発者のための機能が不足していることがただただ惜しまれる。


■ 2013/10/31 2:00 トーナメント


本戦のトーナメント

f:id:yaneurao:20131031020417p:image

http://ex.nicovideo.jp/denou/tournament/rule.html


A,B,C,Dのいずれのブロックでもいいので残れば4位以内であることが確定する。

予選1,2,3,4位のソフトは1度負けても100%の権利で敗者復活に参加できる。つまり予選1〜4位は自動的に本戦2日目まで参加。


逆に、予選で勝ち残って本戦で最短で終わるパターンは予選5〜12位で本戦1回戦負け。この場合、敗者復活がないので1回の対局でお帰りである。(とは言っても持ち時間が双方2時間あるので4時間ぐらいかかるんだが…) 予選が5位〜12位でも1回でも勝てば、敗者復活の権利が得られるから2日目に残留確定。


■ 2013/10/31 2:05 トーナメント攻略


さて、どのブロックがやねうら王にとって一番有利だろうか?


やねうら王より強いソフト(1,2,3と仮定)と当たった場合、勝率は3割だとする。

やねうら王より少し強いソフト(4と仮定)と当たった場合、勝率は4割だとする。

やねうら王と同等のソフト(5,6,7と仮定)と当たった場合、勝率は5割だとする。

やねうら王より弱いソフト(8,9,10,11,12と仮定)と当たった場合、勝率8割だとする。


予選1位抜け→Aブロック代表になる確率 80%

予選2位抜け→Cブロック 80%

予選3位抜け→Dブロック 56%(6と11は6が8割勝つとして、80%×50% + 20%×80% )

予選4位抜け→Bブロック 50%

予選5位抜け→Bブロック 40%

となる。


予選で少しでも上位のほうが本戦で上位になる確率は高くなるようになっており、番狂わせがあまり生じないようにうまく配慮されていると思う。


仮に予選4位のほうが予選3位よりブロック代表になる確率が高いのなら、戦略上、狙って負けるという方法もあるのだろうけど、上の計算によるとわざと負けるのは損っぽい。


ただし、事前に公開されているプログラムが仮にあるとしたら、この状況は変わってくるかも知れない。事前に公開していてそのソフトには100%勝てるとわかっている状況であるなら、そのプログラムと当たるためにわざと予選で負けたほうが得なケースは存在するだろう。まあ、ソロコフが絡むのでわざと負けて狙った順位になるのは至難の業かも知れない。



■ 2013/10/31 2:20 将棋所でBonanza(+u2b)が固まる件


コメント欄でご教示いただきました。

ボナンザが投了時に固まる件についてですが、解決策になるか分かりませんが、将棋所の作者の方がu2b.exeの代わりに使うbonadapterというツールを公開されていますので、使ってみてはどうでしょう

http://www.geocities.jp/shogidokoro/bonadapter.html

bonadapterについては知ってましたが、u2bをわかりやすくしただけだろうぐらいに思っていたのですが、いろいろ改良されてます。


投了時に停止する問題はもちろん解決されていますし、あと、思考エンジン設定がわかりやすいです。将棋所側の持ち時間設定も守ってくれるみたいですし、これで開発が少し捗ります。またx64環境でSSE4が使えるならbonanza_x64_sse4.exeのほうを実行するようです。なかなか気が利いてますね。


ちなみに定跡がnarrow bookでないほうがデフォルトになっているようで、そのままの設定だと糞みたいな定跡を選択します。これu2bではデフォルトはnarrow bookだったと思うのですが。bonadapter使って、「Bonanza6に8割勝つようになった〜」とか喜んでても、実はnarrow bookでないだけとか、そういうオチもありえます。


ともかく、素晴らしいツールを提供している将棋所の作者に感謝!


■ 2013/10/31 2:45 Bonanzaは入玉が弱い件


Bonanza6をBonanza6と自己対戦させているとよく入玉模様になる。対局条件にもよるのかも知れないけど5局か10局に1局ぐらいは入玉模様になる。


入玉阻止のための金を打っておけばいいだけなのに、Bonanza6はそれすらしなくて入玉模様になる。Bonanza6のfv.bin、あれ玉が4段目以上にいる場合に上空にある敵の金の価値を手で補正してやれば入玉が阻止できるようになって勝率が上がると思う。


本当、つまらないhackだけどこういうの実に効果がある。


Bonanza6のfv.binについては過学習しているところを均して、入玉絡みのところを手で補正すれば3駒関係の本来の力を引き出せると思う。


まあ、これについては来年のやねうら王で成果を…。


■ 2013/10/31 3:50 Bonanzaが強い理由


Bonanzaが安定して強いのは、バグがほとんどないからだ。ソースコードが公開されており、たいへん読みやすいので多くの研究者ソースコードをこねくり回し、その結果、ほとんどの致命的なバグは修正された。私もそのバグ潰しにずいぶんと貢献した。(つもり)


コンピューター将棋はいくつかバグがあっても普通に動いてしまうことだ。探索まわりなんて特にそう。1手詰めがバグっていようが、ほとんどのケースで問題はなく、たまーに、探索の末端でそれが問題となる局面があるとわずかに影響が出る程度だ。


しかし、そのわずかな影響が積み重なって、思考エンジンは蝕まれていくわけである

そしてどこかの時点で「何故か知らないけど以前のバージョンより弱くなっている」と気づくわけである


200戦程度自己対戦しただけでは、なかなか本当のところはよくわからない。


結局のところ、思考エンジンは大変複雑であるにも関わらず、その思考にまつわる部分においてバグは限りなく0%でなければならない。これは平均的なプログラマーが一人で開発している場合には到底達成不可能な目標である


もちろん、ベテランプログラマーにとってもこの規模のソースコードバグ0%というのは大変過酷な条件なので、StockfishやBonanzaなどなるべくロジック上のバグが0%に近いとわかっているオープンソースソースコードを参考にしながら、なるべくバグのないプログラムに仕上げるわけである


それでもバグはたまに仕込んでしまうので、ソースコードをきちんとバージョン管理して、以前のバージョンより弱いと感じたら、以前のバージョンと差分を取り、いままでの修正箇所を順番に追跡し、検証していくような、そういう地道な作業を繰り返しているわけである


Bonanzaと言うとボナンザメソッドばかりに注目が行くが、バグが限りなく0%。

これがBonanzaの強さの秘訣だと私は思っている。


■ 2013/10/31 13:40 長手数の詰将棋ルーチンは必要なのか


コンピューター将棋研究の偉大な成果としてボナンザメソッド以外にdf-pn+がある。これは長手数の詰将棋を瞬く間に(?)解いてしまう凄い奴だ。研究成果としてはボナンザメソッドと双璧を成すと言っても過言ではないだろう。


ところが、df-pn+はなかなか実際のコンピューター将棋に採用されない。実装が非常に難しいこともあるし、df-pn+のアルゴリズムについて書かれた論文の説明の仕方が悪く、非常に理解しづらいからというのもある。それとは別に、採用してもあまり勝率が上がらないからというのもある。


Bonanzaでもdf-pn+による詰将棋ソースコード上は実装されているが、1PCのときはたぶんこのルーチンは使わないだろう。


それは、なかなか長手数の詰将棋が出現するような局面にならないというのがあるし、そもそも詰将棋で勝てる局面というのは自分有利な局面のはずであり、そんな長手数の詰将棋に頼らずとも他にも勝ち方があることが多いからというのもある。


また、その「自分有利な局面」まで持っていくために、df-pn+はほとんど寄与しない。寄与しないどころか、詰みもないのに通常探索の時間をいたずらに消耗する、悪玉コレステロールのような存在である。これでは「自分有利な局面」になるものもならない。


このへんは対局条件にもよる。短い時間だと頓死を食らいやすいのでα値を更新したときに3手詰め(Bonanzaのmate3.c)を呼び出すことには意味がある。その3手詰めをdf-pn+に変更することにもたぶん意味があるだろう。


長手数で本当にそんなに頓死するものなのかどうかはそこまで実験する時間がないので私にはよくわからない。そもそも、通常探索でも王手となる手はそれなりに延長されるわけで、1手3秒でも15手詰めぐらいは読める。


持ち時間が長くなったとき、あるいは、マシンスペックが向上したとき、どれくらいの頻度で長手数の詰みの見落としによる頓死を喰らうのか。そこらへんは今後の研究課題なのである。(たぶん)



■ 2013/10/31 13:55 入玉対策


やねうら王は入玉対策をしていない。いまからでもしたほうがいいとは思うのだが、下手にいじりたくない。


持ち時間が短いとするっと上部に逃がしてしまうことはあるのだが、持ち時間が多くなってくると寄せ間違いみたいなのはずいぶん減るわけで、入玉される率自体は下がると思うのだが…。


それでもいまから対策できるものなら…したいのだが…。考え中である


■ 2013/10/31 14:00 将棋ソフト


将棋ソフト動物の名前とか食べ物の名前とかをつけるのが流行りである。(たぶん)

兎(うさぴょん)、ひよこ、クマ、カツ丼などがある。


ひよこ将棋が、プロを打ち負かした場合、

プロ棋士「こんなひよっ子に負けるだなんて…」


カツ丼将棋が、プロを打ち負かした場合、

プロ棋士「こんな食い物に負けるだなんて」


など、プロ棋士としても嫌なものがあるのではなかろうか。


ボンクラーズのときも故米長会長から当初は「(ボンクラに負けるのは嫌だから)プロとやるときはこの名前を変えてくれない」と言われていたらしい。*2


その点、習甦なんか、文字の中に「羽生」の文字が入っているので、「羽生さんに負けるなら仕方ない」みたいとプロ棋士も諦めがつくのではなかろうか。


そういう意味では、「やねうら王」ぐらいではまだまだインパクトに欠けるので、来年は「やねうら神」ぐらいにして、プロ棋士に「神様に負けるなら仕方がない」と思わせる感じにしたらどうかと思っているのだが。(冗談です)


■ 2013/10/31 17:30 TDDでコンピューター将棋バグは減らせるのか?


コメント欄での質問にお答えします。

> Bonanzaが安定して強いのは、バグがほとんどないからだ。

TDDをやるのと、こういうのを作るのは相性がわるいんでしょうか?


ソースコード上に大量にassertは入れてあって、実行時におかしな挙動になればすぐにわかるようにはなっています。(まともな思考エンジン開発者ならば)


しかし、TDDでは探索に関係するバグはなかなか見つけられませんね。


探索の深いところの結果が問題になるので、実行時に直接的に落ちるとかそういうわけでもなく、また、探索は少しパラメーターを変更すると探索結果は変わるものなので、探索結果が以前のものとの同一性が問題となるわけではないので、テストパターンの書きようがないのです。


将棋問題集の問題を解かせて、その解答速度や正答率が落ちていれば怪しいとは言えるでしょうけど、その問題集も何万問もの問題セットがないとあまり意味がないでしょう。100問やそこらやったところで何もわからない(ベンチマーク的な指針にはなりますが)というのが本当のところです。


そういう意味では、何万行も書いて一つのバグも出さないという職人芸的な仕事が要求されます。


平均的なプログラマーにはこれが大変困難なので、探索のアルゴリズムを改良とか、学習アルゴリズムの改善だとか、新しいアルゴリズムを試すだとか、そういうこと以前に、まず将棋ソフトとして完成品に至らないのです。


■ 2013/10/31 17:35 fv.binの改造方法について


Bonanza6のパラメーターの可視化は、スズメレンダラーの人(クマ将棋の作者)がやっているので、さっきその公開されているツールをダウンロードして動作とかソースコードとか確認したのだけど、私が思っているようなツールではなかったでござる。


bona6.0の3駒評価の可視化

http://d.hatena.ne.jp/suzume_r/20130904


やりたいのは、玉の位置およびもう一駒(or ニ駒)をユーザーインタラクティブに動かして、そのときに大きな点数のつく三駒関係を調べたり、ニ駒を固定しておき、三駒関係の値をgridみたいなので編集したりすることなんです。手でチューニングする上でそういうツールが必須なんです。ホント、お願いしますよ〜、雀ちゃん!(←馴れ馴れしいな!)


■ 2013/10/31 17:45 クラウド開発手法


今回の電王戦に参加する他の思考エンジン開発者でこの時期にブログを更新している人は私以外にはほとんどいないようだ。


私とて、暇だからブログを更新しているわけではなく、ここにアイデアを撒き散らすことにより、面白いと思ってくれる人が集まり、そして大量に人が訪れることにより、秀逸なアイデアコメント欄に書き込まれ、それを頼りに開発するという、いわばクラウド開発の新しい形をブログを通じて実験的に行なっているわけである


今回は電王戦不参加になった大合神クジラちゃんであるが、あのアイデアも結局、ソフトおよび作者のカリスマ性やソフトの目新しさ、ソフトの人気などを利用して注目を集め、その力をマシンパワーに転化しようという意味で私と根本的な考えかたは同じなのである。(クラウドファンディングに通ずるものがある。)


今回、ブログコメントで私はずいぶん助けられているので、ブログを書くのに費やした時間よりもらえたコメントの価値のほうが上回るはずである。だから今回ブログを書きながら開発をして良かったと思っているし、読者の方には感謝しているのである


■ 2013/10/31 17:50 いまから評価関数をいじる!


「お前は一体何を言っているんだ」という感じですが、いまから評価関数を改造します。いじったあと、朝まで200局ほど前バージョンと対戦させてみて、動作が不安定および、勝ち越さないようであればrevert(前の状態に戻す)します。


あらかじに書いておきますが、入玉対策ではありません。

入玉対策は…明日までに何か素晴らしいアイデアが思いつくといいのですが。


■ 2013/10/31 20:35 評価関数の改良が半分ぐらい


評価関数の改良、半分ぐらいソースの改造が終わったところでメールをチェックしたら大量に仕事が来てた。いまから片付けなければならない。ほんと、勘弁して欲しい。


今回、電王戦やねうらおはカネ目当てで出るのかと言われているが、そうだ。私は金が欲しいのだ。何もいままで開発に費やした分の労力に見合う報酬をくれと言うのではない。電気代だ。いままで開発のために使った電気代を一部でいいから返して欲しいわけだ。


だいたい、Bonanzaのfv.bin(評価関数パラメータ)にしても当時の最先端のXeonマシンを3ヶ月もぶん回して(それ以前の試行錯誤も含めるともっと大量の時間だろう)作られたものである。つまり、機械学習やら何やらにはお金がかかるのである。仮に最先端のPCで10万時間の計算時間を費やして作られたfv.binがあるなら、何十万円もの価値があるだろう。つまりは、学習させたパラメータファイルに値段がつく時代なのである


機械学習の結果を直接的に売り買いするようなビジネスというのはあまり聞かないが、そういうビジネスは当然成り立つのである


■ 2013/10/31 23:50 やっと終わった!(違うほうの仕事が)


評価関数の改善に取り組む。計算が難しくて一発で正解となるコードを書ける自信がないけど…。

紙の上での計算は出来たので、もうちょっと頑張ってみます。


■ 2013/11/01 0:50 将棋所での置換表のサイズ設定について


やねうら王のほう、本番マシンで置換表サイズをどれくらいにしようかと悩んでいたのだが、使える以上、最大サイズにしようと思うに至った。


そのためには少なくとも8GBでうまく動くかテストしておきたい。(どこかでオーバーフローするかも知れないから)


ところが、私の持っているマシンは16GBのものしかない。将棋所で8GBと設定すると、もう片方の思考エンジンにも8GBと設定されてしまい、置換表だけでPCの全メモリを使いきってしまう。(なんてこったい…。)


将棋所はどうして片側の思考エンジンごとに置換表サイズを設定できるようにしてないのか首を傾げてしまう次第であるが、ともかくろくにテストもできないので電王戦トーナメント予選の日に会場でテストしようと思う。


この他にもやねうら王には「会場でテストする」予定の項目はたくさんあって、「これでまともに対局できてたら奇蹟じゃねーの」というぐらいの状態である。でも勝つ。ここから勝つ。勝っていままでの電気代を取り戻す!



■ 2013/11/01 2:45 評価関数の改造失敗した…/(^o^)\


速攻revertした。せっかく書いた5時間が水泡に帰した…。


■ 2013/11/01 2:50 やね裏学習メソッドに対するこだわり


言っときますけど、やね裏学習メソッドにこだわりはないですよ?


だいたい、やね裏学習メソッドだのやね裏定跡だの言っても、そんなものはドワンゴの窓口の人からアピールポイントについて書くようにメールが来たので何か返さないとと思って1分ででっち上げた嘘っぱちである


その嘘っぱちを1週間ほどの期間で実装できたんだから、嘘から出た実と言うより他ないが、私としてはこのメソッドに全くこだわりも、何の思い入れもないわけである。単に、出来れば面白いだろうなーというレベルのアイデアだったわけである


この手のアイデアは、誰だっていくらでも出せるだろうし、実装するのも(腕のあるプログラマーにとっては)容易である。思考エンジンの探索部や評価関数の改良と違って試行錯誤がほとんど発生しないから、だいたい期日通りには出来る。


私の場合、間でちょくちょく他の仕事が入ってくるというのと、今回、3年前のソースコード(それも大改造の途中のもの)からのスタートだったので余計に時間がかかったというだけだ。本来なら2日もあれば十分出来て然るべき内容なのだ


それに対して、思考エンジンとして棋力を上げるための改良は大変だ。丸一年かけても全く改善しない場合だって多々ある。私はそういうのに耐えられそうにないのでささっとコンピューターチェスで成功しているアイデアや、他の分野で成功しているアイデアのみを取り入れて書いてしまうのだが、今回いろいろ試してみて、コンピューター将棋の開発って、本当は大変なんだなと思いを新たにし、そして他の開発者の人たちに敬意を払わなければと思った次第である


ああ、でも今回の電王戦でいままで費やした電気代はキッチリ返してもらうけどな!ヽ(`Д´)ノ


■ 2013/11/01 3:16 コンピューター将棋、弱すぎるな…


人類未踏の、人外の領域まで達したとかまことしやかに噂されているコンピューター将棋ソフトではあるが、自分で作ってて言うのもなんですが、序盤が弱すぎますわ。


動作テストしてるとよくわかるのだけど、定跡を入れていないと平気で相手に穴熊に組ませて、「形勢互角やで、どや?」みたいなドヤ顔で評価値±0とか出しやがる。0じゃねぇわ、その局面。圧倒的大差だぜ。


こんなのが本当に強いのか。確かに終盤はべらぼうに強いが(入玉以外は)、将棋は終盤だけで決まるゲームなのか?それならそれで、人間側も優勢の終盤を勝ちきるための技術をもっと磨くべきじゃないかと思うわけだ。


コンピューター将棋の終盤には新手筋みたいなのはたくさん隠されている。そういうのを問題集のような形にして、そこから人間が学べば大きく棋力が上達するに違いないのである


■ 2013/11/01 11:22 Bonanza入玉将棋


Bonanzaは入玉将棋が弱いと言われているが、玉が中段のときに、その上空にある敵の金に点数がついていないのかと思ったら、きっちりついていた。多少変な点数になっているところがないではないが、十分意味のあるスコアリングと言えると思う。


つまり、入玉阻止が悪いのではなく、入玉に対する評価が甘すぎるのだろう。玉が敵陣まで行ったらスコアとしてプラスαすれば一応はマシにはずで、一番手軽な対策はそれだろう。(やねうら王は検証する時間がないのでそれはやっていないが)


あと、KKP(3駒関係)より、まずはKP(2駒関係)のほうでいろいろ問題のある数値がある。KPなら手で編集するのも不可能ではない範囲なので、これについては今後検討する。


いずれにせよ、棋譜の質でも評価関数の精度が変わるが、棋譜の質を上げると棋譜の数が減る。棋譜の数が減ると出現しない特徴因子が出てきて、その特徴因子が未学習のままになる。(その特徴因子の値はほぼ0になる)


それを考えると棋譜の質を上げたほうがいいのか、棋譜の数を増やしたほうがいいのかは判断の難しいところだ。


■ 2013/11/01 11:30 Bonanzaの終盤弱いんですけど


Bonanza6の終盤、他のソフトより明らかに弱い。詰将棋探索がないとか、そんな次元ではない。王手に対して探索延長しているのだけど、ここの条件が甘くて、なんでもかんでも延長しているような、そんな状態になってろくに探索できていない。これでは勝てない…。


王手状態のノード割合

http://d.hatena.ne.jp/suzume_r/20131007


ただ、その分、Bonanzaは序・中盤にそこそこ頑張るので、どっちかと言うと中盤で頑張って、そのあと逃げ切るのがBonanzaらしい戦い方なのだろう。


■ 次記事


電王戦 --- 将棋電王トーナメント --- やねうら王特設ページその3

http://d.hatena.ne.jp/yaneurao/20131101#p1

t_tutiyat_tutiya 2013/10/28 09:23 なむなむ(祈祷)

kyawakyawa 2013/10/28 10:12 祈っております!

EdisonDenEdisonDen 2013/10/28 10:21 http://www.amazon.co.jp/exec/obidos/ASIN/4774136689/aaaaab0c-22/ref=nosim/ ←今まさにこれ読みながら、一発神調整の降臨を祈っております!

elgooelgoo 2013/10/28 10:50 期待してます!評価関数のそれぞれのパラメタの値は、ボナンザと似たような感じになるもんなんでしょうか?それとも似ても似つかぬ値になってしまって、それでも一定の強さを発揮するようなものなんでしょうか?ちょっと疑問に思いました

yaneuraoyaneurao 2013/10/28 12:18 ↑長文になりそうだったので本文中で回答させていただきました。

玉ねぎ坊や玉ねぎ坊や 2013/10/28 23:35 今回の電王戦を盛り上げる為にもやねうら王さんのような存在が必要不可欠だと私は感じてます。恐らく主催者側もインパクトがあってかつ新鮮な人が5候補に入ってほしいと切に思っているはず。前の伊藤さんまでの悪役には仕立てられないと思いますが・・・(^_^;)。プログラムの調整とご自身の体調の調整に頑張って下さいませ。

たけたけ 2013/10/29 00:58 祈ってます!

hey-jeyhey-jey 2013/10/29 02:12 ここを見る限り、やねさん一人で作ってる気がしますが、もう一名の名前が挙がってる方は何を担当されてるんでしょうか・・

yaneuraoyaneurao 2013/10/29 02:52 ↑彼は会場に来て、支給されたお弁当を食べる係の人です。(とか言う)

piro77piro77 2013/10/29 19:57 将棋所はデバッグウィンドウを出すとコマンドが送信できるようです。即指しは人間相手だと相手の考える時間を減らせるとかもありそうですが。いろいろ難しいですね。学習は収束しているのでしょうか。祈祷しておりますw。

yaneuraoyaneurao 2013/10/29 20:03 ↑おお、デバッグウィンドウからサーバーに送信できるんですね。ありがとうございます!

kanokekanoke 2013/10/30 00:28 なんだかブログ更新が多いので心配ですが、祈祷しておきますね。なむあみだぶつ…。
あ、そうそう。量子将棋が話題になってますね。めっちゃ面白いですよ。

se-kise-ki 2013/10/30 02:07 追い込みに計算資源必要ならさくらのクラウドでも使えばいいんじゃないですかね

yaneuraoyaneurao 2013/10/30 09:00 ↑*2 量子将棋、面白そうですね。電王戦終わったらやってみます。
↑*1 さくらのクラウド、そこそこ安いのですが、さすがに常時CPU負荷100%にしたら怒られるんではないですかね…。

odakinodakin 2013/10/30 11:36 ご成功お祈り申し上げます( ̄人 ̄)

通りすがり通りすがり 2013/10/30 20:09 個人的に実用新案レベルの発想じゃないかと勝手に思っているのですが、
メソッド?で行う評価のストックの際に行う学習(再探索)を逆順に行えば、
評価関数に致命的な問題が無い限り、より良い結果を得られるのではと
思うのです。

たとえば、114手で投了したとすると、113手から初めてデクリメントして
行くようにすれば、前の手の評価はトランスポジションテーブルに存在する
ので、大局的に見れば、終盤までを一気に探索するPAB的な探索木の構造に
なると思います。

対局者が自身よりも優れた手を指している場合、局面の過剰評価が
判断できると考えられるので、それをストックしておいた方が
良いような気がしますがどうでしょうか?(実装も簡単だと思うし)

まぁ、終局後検討すんだから逆から考えるのは当然だろと言われるとそれまでですが・・・・(´・ω・`)

yaneuraoyaneurao 2013/10/30 20:34 ↑少し長くなりそうだったので本文中で回答させていただきました。

通りすがり 通りすがり 2013/10/30 21:38 >>私の実装も逆順で検討するようになっています。

そりゃそうですよね。特に詰みが絡んでくるとなれば。
将棋所とかも逆順で検討してくれたらいいのに・・・・。

また、トーナメント後などで時間が出来た時に教えてください。

ボナンザのgpw2006.pfdとかを見ると、学習に使う探索は1手読程度みたいですが、
これは現在も変わってないんでしょうか?1手読でも6万譜も集めれば膨大な数の
節(項と言うべき?)になるんでしょうけど。あと、ボナメソって、結局やってる
ことって、線形計画を何回も解いて、節の重みを変えて一致率を上げてると
考えてよいんでしょうか?

あと、深い探索と評価値を合わす学習は、評価値との差の2乗を最小化するような
二次計画問題と考えてよいのでしょうか?

結局何が聞きたいかと言うと、最適制御論理って理解しないといけないの?
最急降下法とか分かんないよ。って人は、ボナメソは扱えないのかと言う点です。
(プログラマたるもの其れ位はせめて理解せよってのはあるのかもしれませんが、
プログラマのプロはプロフェッショナルを意味してるわけじゃないし・・・)

最急降下法とか全然知らなくても、問題を定義することは比較的容易に出来ると思います。
問題定義できたなら、SCIPとかのソルバーに問題を食べさせて解くことは出来ないのかと
・・・やってる人が、いるならそれだけで、ボナメソの敷居が下がりそうな気もするん
ですけどね。

yaneuraoyaneurao 2013/10/30 21:52 ↑Bonanzaの学習は1手ではなく3手です。その他は、ググるか、Bonanzaのlearn1.c/learn2.cとevaluate.cを比較しながら読めばわかることなので割愛。

wainwain 2013/10/31 01:32 将棋所に切れ負けが無いのは直接要望された事が無いからという落ちのような気がします。
作者は連続対局時に問題になることがあることは認識されているようですし。

candlecandle 2013/10/31 01:58 ボナンザが投了時に固まる件についてですが、解決策になるか分かりませんが、将棋所の作者の方がu2b.exeの代わりに使うbonadapterというツールを公開されていますので、使ってみてはどうでしょう。
http://www.geocities.jp/shogidokoro/bonadapter.html

yaneuraoyaneurao 2013/10/31 02:07 ↑*2 う〜ん、そうなんですかね…。うーむ..
↑*1 はい、bonadapterなら大丈夫かもと思っているのですが、まだ試していません。このあと試してみます。

yaneuraoyaneurao 2013/10/31 02:22 追伸 : bonadapterで改善されている気がします!本文に書きました。このまま一晩寝かせてみようと思います。ありがとうございました。

かず@Calamityかず@Calamity 2013/10/31 02:48 Blunderのak11さん作のGUIはどうなんでしょうか?
http://d.hatena.ne.jp/ak11/20130114#p1
対局は素直にBonanzaをCSA_LANを有効にしてコンパイルして、shogi-serverをローカルで動かして対戦させるとか?

かず@Calamityかず@Calamity 2013/10/31 02:51 しょうもない質問ですけど、会場にやねさんの著書を持っていくと一筆書いていただけたりするのでしょうか?その場合は何を持っていくか悩みますけど。

yaneuraoyaneurao 2013/10/31 02:54 ↑おお!去年、aki.さんが作るとか言ってるのをメールで聞いたのですが、そのあと私のほう仕事が忙しくなってまったくウォッチしてませんでした。そうでしたか…。あとでチェックしてみます。

BonanzaのCSA_LAN機能ってそういう意味だったんですね…。知りませんでした…。(興味なかったのでその部分のソースコード読んでませんでした…)

本当、何から何までありがとうございます。予選リーグではよろしくお願い致します。

yaneuraoyaneurao 2013/10/31 03:35 ↑*2 私の小学生の落書きみたいなサインを本にしたら、二束三文になりますよ!ヽ(`Д´)ノ

IKeJIIKeJI 2013/10/31 16:55 > Bonanzaが安定して強いのは、バグがほとんどないからだ。
TDDをやるのと、こういうのを作るのは相性がわるいんでしょうか?
素人目には相性よさそうなんですが。

通りがかり通りがかり 2013/10/31 17:03 以前、古本を購入したとき、
----------------------------------------------------
お客様よりご注文いただいた商品の検品作業をした際、
品質の不備が判明いたしました。
 商品名 :解析xxxxx
 不備理由:書込み(サイン)あり
ご利用をされる分には差しさわりが少ないかと存じますが、
お客様からお代金をいただけるお品物ではないと判断し、
商品代金および送料を無料にて本日発送させていただきます。
----------------------------------------------------
で、ホントにタダになりました。

yaneuraoyaneurao 2013/10/31 17:24 ↑*2 長くなりそうなので本文中で回答させていただきます。
↑*1 わはは。

suzume_rsuzume_r 2013/10/31 20:55 fv.binの編集GUIツールの作成、是非とも期待しております。

yaneuraoyaneurao 2013/10/31 21:25 ↑え…私ですか。マジですか…。考えておきます。

トラックバック - http://d.hatena.ne.jp/yaneurao/20131028

2013-10-25 電王戦のドワンゴの対応が糞対応すぎる件

[] 電王戦ドワンゴ対応が糞対応すぎる件  電王戦のドワンゴの対応が糞対応すぎる件を含むブックマーク  電王戦のドワンゴの対応が糞対応すぎる件のブックマークコメント


電王戦トーナメントの出場者の詳細プロフィールが掲載されたんですけど、掲載した旨のメールみたいなものは出場者の私に来てないんですよね。


電王戦トーナメントの出場者の詳細プロフィール

http://ex.nicovideo.jp/denou/tournament/soft_profile.html


というか、掲載する前に普通、この内容で大丈夫かだとか確認するのが普通であって、確認もなしで、掲載したあとの連絡も無しで、ついでに言うと私はプロフィール、一箇所文章がおかしいところがあったので修正の依頼メールを事前に送ったのに、そのメールにリターンも無いという、真っ当な企業では到底ありえないような糞対応なんですけどね。


ついでに言えば電王戦トーナメントエントリー申請は9月24日にしたんですけど、申込みフォームから送信しても自動返信メールすら来ない有り様で、本当に申請できているかもわからない状態のまま、そのあとエントリー受付締め切り後の10月1日になってから将棋電王トーナメントエントリーいただき誠にありがとうございますとか5行ほどの短いメールが来ただけで…。


さらに書けば、郵送で送られてきた参加申し込み書には、次のように書かれてます

上位1位から5位になった申込者には、下記の義務が生じます。(中略)
・第三回将棋電王戦に出場すること
・12月上旬中旬に行われる第3回将棋電王戦記者発表会及び関係番組等に
出席・出演すること
・主催者、報道機関等によるインタビュー等に応じること

「関連番組」がどれだけあって、「報道機関等」がどれだけあるのかもわからない大変不透明極まりない内容を要求されます交通費は出るとは言え、ノーギャラですから、5位の30万だと全然割に合わない可能性すらあります


これ、GPS将棋激指のような大学関係者ですと、年末の忙しい時期にこういう条件が義務づけられていると出場しにくいのではないでしょうか。


私も上の条件はかなり嫌なものを感じますが、賞金が欲し将棋文化の発展に寄与するためにも出場し、出場するからには尽力したいと思います


■ 2013/10/26 13:30 追記


ドワンゴ電王戦の責任者の方から私のほうにお詫びの電話とメールがありました。

「窓口担当者に厳しく指導し、今後の対応の改善に努めて参ります」とのことだそうです。


また、参加申込書の条件に関しては、

又、参加申込書にも乱暴な条件が含まれていた事、お詫び申し上げます電王戦を盛り上げていく上で、開発者の皆様にも可能な範囲でご協力
いただきたいと考えての事だったのですが、非常に押し付けがましい
文面となっており、申し訳ございませんでした。


初めてのコンピュータ将棋の大会運営で、至らない点が多々あるかと
思いますが、本大会を通じて、コンピュータ将棋の発展に貢献したいと
考えております

とのことだそうです。


コンピューター将棋が名人・竜王に匹敵する強さに到達しようとしている(到達している?)現在においても、コンピューター将棋のタイトル棋戦と呼べるもの電王戦しかない状況ですから、本当にコンピューター将棋の未来はドワンゴ様次第であると言っても過言ではありません。今後とも電王戦主催のほう、何卒よろしくお願い致します


■ 関連記事


電王戦 --- 将棋電王トーナメント --- やねうら王特設ページ

http://d.hatena.ne.jp/yaneurao/20131013#p1


第3回将棋電王戦にでます

http://d.hatena.ne.jp/yaneurao/20130823#p1

えびえび 2013/10/25 22:48 だって、ドワンゴは勝手に投稿動画をテレビで放映し、
そのことを権利者が権利を主張すると「権利を主張されると困りますよ」と、ドワンゴ役員の横澤さんがいうような会社ですよ。
詳しくは三重の人あたりが書いてます。

通りすがり通りすがり 2013/10/26 02:46 『全て』出席・出演すること、『全ての』インタビュー等に応じることとは書かれていませんし、『2回以上』出席・出演すること、『2回以上』インタビュー等に応じることとも書かれていません。故に、仕事に支障が出るなら、それぞれ1回でいいと思いますよ。インタビューも『口頭で』とか『ビデオで』とも書かれていないので、メールやツイッターでのみ受け付けるのも禁止されていません。

このことによって、誰かが迷惑受けるわけでないので、他の方もそれぐらい図々しくてもいいと思いますけどね。

yaneuraoyaneurao 2013/10/26 03:14 ↑「Xすべし」と書かれている場合、複数あるXのうち1つでもやればやったとみなされるのか、すべてやらないといけないのかはよくわかりませんが、まあ、ドワンゴ側にそこまでの悪意はないと私は信じておりますので、そのへんは話し合いでなんとかなるのかなとは思いますが、とりあえず書面上はそうなっていました、という話でした。

玉ねぎ坊や玉ねぎ坊や 2013/10/26 07:25 そんな一方的な紹介文だったんですね!
その話をから類推すると向こうもまだまだお子ちゃんということでしょうか。他の開発者も迷惑を被ってそうですね。こういう場合は私ならメールではなく直に担当者に会うか電話します(笑)
まあそこまでしなくても良いのなら子猫を見守る親猫の心構えで良いのかなとも。
まあやねうら王さん。5位以内入ったって
くださいよ。そうしたら向こうも否が応でも言うこと聞いてくれるに違いありませんから。

かず@calamityかず@calamity 2013/10/26 12:52 募集段階では電王戦出場ソフトだけ提出だったのが、確認書だと参加ソフトになってたりとかw
あと5位は30万ですね。

yaneuraoyaneurao 2013/10/26 13:23 ↑おお、30万でしたか。本文修正しました。

30万(源泉徴収されて27万?)ですと、数回泊りがけで地方から東京まで行くと移動の時間等を考えると、ノーギャラだと完全に赤字ですな…。(交通費と、宿泊費に関しては出してもらえるようですが)

まあ、そうは言っても世界コンピュータ将棋選手権のように参加費に1万円払って、自前でハイエンド機を用意して、それで優勝してもノーパソ1台というのに比べれば電王戦は条件的には恵まれているほうですから、これで良しとすべきなんでしょうね。

コンピューター将棋にも、もっとタイトル棋戦のようなものが出てくれば面白いと思うのですが、テレビ局が扱ってくれるようになるのはまだまだ先なのでしょうか…。もうコンピューター将棋は名人・竜王に匹敵するレベルになっているというのに…。

anonymousanonymous 2013/10/26 19:05 コンピューター将棋は、一手を指すのではなく、絞り出せるようになった時に文句なしで面白くなりそうです
後、もっと派閥争いとかあってもいいですよね
人となりといいますか、語られるべき逸話があれば素晴らしいと信じていますよ

トラックバック - http://d.hatena.ne.jp/yaneurao/20131025

2013-10-20 河童のおっさんの話

[] 河童おっさんの話  河童のおっさんの話を含むブックマーク  河童のおっさんの話のブックマークコメント


電話がかかってきて、電話に集中し、電話が終わり、ふと画面を見たらDropboxが(同期した日付として)「たった今」とか表示している。この「今」という文字なのだが、ちょっとよそ見していると、ベロ(舌)を出してやがる気がする。


こんなことを言うと頭がおかしいと思われかねないことは重々承知だが、あっちむいて、ふと見たときにこいつは絶対ベロを出していると思う。


きっと私が見てないときには、「だるまさんがころんだ」遊びみたいな感じで、ベロをずっと出してやがる。


でも私が見た瞬間、ベロを引っ込める。でもそのベロを引っ込める動作がいつもわずかに見える。絶対、私が電話してるとき、こいつはずっとベロを出してやがった。間違いない。


これだけ言っても、何のことだかわからない人もいると思うので、さっき、そのベロを出している決定的瞬間を捉えようと思った。こいつは、そのまま私が見てないふりをしていると油断してそのままずっとベロを出してやがる間抜けな奴だ。ほら、ずっとベロを出しているではないか。よし、スケッチしよう。スケッチして皆に見せてやろう。そのままずっと動くなよ…。



f:id:yaneurao:20131020214213p:image


こうだ。こうなっているのだ。おかっぱ頭の10ハゲのある河童づらしたおっさんがベロを出しているのだ。なぜみんな、これがわからないのだ。よく見ろ「今」を。よく見るんだ「今」を。


な、わかるよな?みんな、もっと「今」を見つめろ。ほら「今」は今もベロを出している。

yaneuraoyaneurao 2013/10/20 22:04 よく見ろ「今」を。よく見るんだ「今」を。← なんだ、この、ここだけ切り出すと凄く名言っぽいが、実は全く名言ではないという不思議な言語現象は!

ゲシュタルト崩壊ゲシュタルト崩壊 2013/10/20 22:32 本当にそう見えたきたよ!気持ち悪いよ!ヽ(`Д´)ノウワアアン

あるあるあるある 2013/10/21 08:45 私は”読む”の漢字が逆さまにひっくり返っている時があります。

i love cs1.6i love cs1.6 2013/10/21 15:45 鬼瓦権造に見えてきた

yaneuraoyaneurao 2013/10/22 13:23 ↑ほんまや!(゜д゜)

トラックバック - http://d.hatena.ne.jp/yaneurao/20131020

2013-10-13 電王戦 --- 将棋電王トーナメント --- やねうら王特設ページ

[] 電王戦 --- 将棋電王トーナメント --- やねうら王特設ページ  電王戦 --- 将棋電王トーナメント --- やねうら王特設ページを含むブックマーク  電王戦 --- 将棋電王トーナメント --- やねうら王特設ページのブックマークコメント


■ 2013/10/13 6:00 特設ページはじめました


とりあえず、第三回電王戦の将棋電王トーナメントに出場する「やねうら王」の開発状況などをここに書いていきます。(定期的に追記していきます)


f:id:yaneurao:20131013061104j:image

将棋電王トーナメント 出場ソフト http://ex.nicovideo.jp/denou/tournament/soft.html


昨日、仕事が一段落したので久々にAppStoreのランキング見たら、テイルズオブハーツRが発売になってて、しかも15日まで半額セールなので速攻購入して13時間もやってしまった…。もうしませんもうしません。><


明日から頑張ります…。


■ 2013/10/13 7:30 やねうら王の特徴


ドワンゴ電王戦担当者から「出場ソフトの特徴」などについて質問メールが来ていたので「ソフトの特徴」として以下のように書いておいた。(公式サイトでの公開および当日の紹介で通知されるらしい) ちなみにまだ以下に書いてあるようなことは何もできてないのだが…。明日から頑張ろう…。


・世界最速の指し手生成ルーチン搭載


 コンピューター将棋の指し手生成ルーチンとして世界最速を誇り、

発表以来、いまだに抜かされたことはない(気がする)、世界最速の指し手生成ルーチン搭載。


・必勝!やね裏定跡


 本大会のために考案された対コンピューター将棋戦略。

 コンピューター将棋のハマりパターンを詰みの局面までインプット

 勝ちパターンにハマればどんな強豪ソフトだろうとまさに一発KO。


・究極進化!やね裏学習メソッド


 従来将棋ソフトのように評価関数を棋譜から学習するタイプの学習ではなく、

一局一局から定跡を自動学習するやね裏学習メソッドを採用。

 一局ごとに進化する世界初コンピューター将棋ソフト


・超軽量!やね裏評価関数


 強豪コンピューター将棋ソフトが評価関数を重量化するトレンドに逆らい、

あえて究極の軽量化を追求したやね裏評価関数。軽さこそ正義!速さこそ我が魂!



■ 2013/10/14 5:30 やね裏学習メソッドについて


定跡の自動学習の仕組みを追加しなければ、プロ棋士ソフトを貸し出して事前研究をされたのでは公式対局において勝てる可能性はグッと減る。そこで、今回出場するすべての将棋ソフトは「やね裏学習メソッド」を採用すべきである。そのためのアルゴリズムをここに書いていく。すこぶる簡単に実装できるので今回出場するソフトの作者は実装すべきである


まず、将棋において、強い人の指す指し手と弱い人の指す指し手との違いは何かということを考えてみよう。


私がR1500(アマ初段)程度だったころ、Bonanzaと対局すると中盤で5手ぐらい進めると明らかに劣勢の局面になった。また5手戻して、別の手を指すのだが、それでも5手ほど進めると同じく劣勢の局面になった。それをしばらく繰り返すが、一向に形勢互角の局面にならず、将棋というのは、なんと難しいゲームなのかと思った。


指し手はどの手もこの手も悪手ばかりなのだ。それは自分の将棋観を根底から打ち砕かれるような衝撃であった。事ここに至り、自分は将棋というゲームを誤って認識していたのだと悟った。


ハイレベルな対局において素人が思っているほどの指し手に自由度はなく、広大な砂漠のなかから一粒の種を探すかの如く、悪手ではない手を探さなければならない。


これを図にすると次のようになる。


f:id:yaneurao:20131014052010p:image


大雑把ではあるが、言いたいことは伝わるはずだ。ある局面において、R500の人が選ぶ指し手の統計をとったときに90%まで網羅しようと思うと20手ぐらいあるとしよう。


R1000の人だと、10手ぐらいしかない。R2000の人だと5手ぐらいしかない。R3000の人だと3手ぐらいしかなく、神様レベルだと1手か2手になると。それが上図の意味するところである


もっとも、R500の人は先まで見越すことはできないので、実戦的にはR500の人が思いつくような指し手の候補のなかに、R3000の人が「必然手」だと思うような手が含まれていないことは多々あるのだが、話を簡略化するためにそれについてはいまは考えないことにする。


上図を見ればわかるように、最終的に同じ指し手を選んでいたとしても、R500の人が選んだのと、R3000の人が選んだのとでは意味合いが異なる。R3000の人が「この局面ではこの一手」だと思うような手を、R500クラスの人の集団のなかで、その指し手を選ぶ人の割合は10%程度かも知れない。R500クラスの人が同じR3000の人と同じ指し手を選んでいたとしても、前者はたまたまくじ引きで10%の確率で当たったにすぎず、後者は100%の確率で当たるくじ引きであったと言える。


将棋というのは、このように1手ごとに最善手を引くためのくじ引きをしているようなものであり、少しでも当たる確率の高いくじ引きをしないと不利になりやすいというゲームだと言える。


さて、これをコンピューター将棋の探索と結びつけて考える。ほとんどのコンピューター将棋は反復深化法と言って一手ずつ探索深度を深くする探索手法をとっている。これは、探索深さNの最善手は、それより一手浅く(N-1の探索深さで)探索したときの最善手と一致することが多く、それゆえ、一手ずつ深くしながら、各局面での最善手を置換表(実体はハッシュテーブル)と呼ばれる表に格納しておくと、一手浅いときの最善手からまず先に探索することで探索時間を短縮化できるからである


まともな評価関数においては、この探索深さが1手深くなるごとにR200ずつ程度上がると言われている。なぜ探索深さを深くすると強くなるのか、その原理的な説明は誰にも出来ない。(それらしい数理モデルで説明することは出来るかも知れないが…)


この件について、篠田 正人氏(奈良女子大学理学部数学科教授にして将棋のアマ強豪。コンピューター将棋にも造詣が深い)に以前、私は直接尋ねてみたことがあるが、私の期待するような回答は得られなかった。(「原理的なことはわからない」という回答であった)


また、まともでない評価関数であると、探索深さを深くしても強くならないのだが、しかし、駒得のみの評価関数であっても探索深さを深くすることにより強くなることは実戦により証明されており(floodgate上での駒得だけの評価関数による実験として「ひよこ将棋」がある)、この場でまともでない評価関数を持ちだしてきて反例を挙げることには何の意味もない。駒得のみの評価関数より粗悪な評価関数など現実的に採用するはずがないのだから。


さて、そう考えたときに、反復深化の深度(イテレーション回数。以下、単にイテレーションと書く)を少しでも上げるにはどうすれば良いのかという話になる。


どの将棋ソフトでもイテレーション3だとR500、4だとR700、5だとR900、…のようにイテレーションを上げるごとに強さがほぼ線形に上がっていく。つまり、同じ思考ルーチンが導き出した答えであっても、R500の指し手、R700の指し手のように、イテレーション回数が多い(思考時間を増やした)指し手のほうが強い指し手である


よって、同じ思考ルーチンであるなら、イテレーション回数が少ない指し手よりイテレーション回数が1回でも多い指し手のほうが圧倒的に価値が高いと仮定して構わない。


この事実を用いてどのように序盤定跡を学習させるかだが、上の仮定があり、また、本大会のように、マシンスペック固定化されているのであれば、単に次のようにすれば良い。


tは、今回の指し手のための思考時間とする。もし、データベース上でこの局面が登録されており、過去、そのときこの局面において思考した時間がtより大きいならデータベース上に登録されている指し手を選択し、今回の指し手のための思考を終了。

思考時間が大きいほうがイテレーションはたくさん回るはずだから、そのときの指し手のほうが圧倒的に優れている(上記仮定より)ので、こうしてしまって何の問題もない。


これにより、一度遭遇した局面の思考時間が短縮化され(定跡扱いで即指しになる)、前回と同じ変化(同一の棋譜)であっても終盤のために持ち時間をたくさん残すようになる。その結果、終盤でたくさんイテレーションが回り、前回より良い手を指せるようになるという仕組みである。つまり、プロ棋士が事前研究をしてきても、研究と同一手順では勝てない(可能性が高い)。


また、本大会のようにPCのスペック固定化されていない場合でも、nps(探索速度)やPCのコア数から、現在のマシンの1秒が、基準マシンの何秒に相当するかは計算できるので、基準マシンの何秒に相当するかという単位で上記の処理を適用してやれば、PCのスペック固定化されていなくともこのアルゴリズムが適用できる。


これが「やね裏学習メソッド」の全貌である。簡単に実装できるので是非、他のコンピューター将棋の作者も実装して欲しい。


なお、コンピューター将棋では従来、定跡は独自形式のファイルとして持たせることが多かったが(そのほうが速いし、それほど複雑な入出力は必要なかったので)、私は今回SQLite3で行なう。


DBのアクセス時間もったいないが、しかし今回の持ち時間であれば相対的に無視できる程度だろうし、また一局終了ごとに定跡として指し手をDBに登録していかないといけないので、独自のファイル形式だとそのへんの処理を書く手間やメンテナンスコストなどを考えると、割に合わないからである


■ 2013/10/14 16:00 やね裏学習メソッドII(局後の自動検討)について


コメント欄のほうで、やね裏学習メソッドでは、「(ボンクラーズが定跡DB通りに進行して)富岡流の必敗局面に足を踏み入れた」ものや、「阿部四段が習甦に対して行った先手番一手損角換わり」のようなものは回避不能ではないかという指摘がありますが、これに関しては次のようにするだけで回避できます。


終局のときに、定跡DB上に自分の指した指し手とそのときの考慮時間を記録するわけですが、コンピューター側が負けたとしたら、それぞれの自分がその一局で指した局面をひとつずつ調べ、それらの局面において、思考時間をDB上に記録されている指し手の思考に使った時間の2倍の時間を用いて思考し、その指し手を定跡DB上に記録しておくだけで良いです。(この局後の自動検討を「やね裏学習メソッドII」と呼ぶことにします。)


これで同じ変化で負けるごとにそれぞれの局面での思考時間は2倍・4倍と増えていくので、原理的には、何度か同じ手順で負け続けていれば、いずれ新しい手を指すでしょう。


まあ、この局後の自動検討で1手の思考時間が数時間ぐらいになってしまいますと、さすがにどうかと思いますが、そのへんはSQLite3を使っているので、1手の思考時間として数時間使っている局面のみリストアップして人間が見て手心を加えてやるぐらいのことは出来るでしょうし、あるいは局後検討で時間を消費しすぎている局面が出現した時点でalertを出し、ソフトの作者にメールを送信して知らせる、みたいなことも出来ます。


将棋倶楽部24や将棋ウォーズのようなオンライン対局サイトコンピューターに自動対局をさせる上で(一日に何千局も自動対局させることを想定)、こういう自動学習〜alertの仕組みは必要不可欠だと私は考えています。


また、このような「やね裏学習メソッド(定跡自動学習)」および「やね裏学習メソッドII(局後自動検討)」を搭載して、floodgateのような他ソフトとの自動対局サイトに放り込んでおけば、他のソフトのハマり定跡を自動発見してくれるというメリットがあります。


この発想こそが、「必勝!やね裏定跡(対コンピューター将棋戦略。詰みの局面まで入力された定跡)」につながっていくのですが、それについてはまた次回にでも。


■ 2013/10/15 9:00 やねうら王 Q&A


コメント欄がごちゃごちゃしてきたので、整理するため、返信が長くなるような質問のコメントは削除して、以下にQ&Aとしてまとめてみました。コメント削除の件は悪しからずご了承ください。


また大会直前までコメント欄にて質問等は随時受け付けています。(私も参考になるものもあるので) 皆様、よろしくお願い致します。(いただいた質問は整理してここに追記していきます。)


Q) 5位に入賞できるかわからないのにプロ棋士との対局のための対策を練っても仕方ないのでは?

A) 客観的に見て、やねうら王は5位に入賞できる可能性はなくもないので、プロ棋士への礼儀としてそれなりの対策を練っておく(それができないなら出場しない)べきかと私は考えています。


Q) プロ棋士がやねうら王に対して再現将棋(事前研究で勝った棋譜を持ってきて対局させる)場合、やねうら王はそれを回避できますか?

A) 中盤ぐらいまではDBに登録されている手の進行となり、その部分の思考時間はゼロ(ルール上は1手につき1秒消費)になります。100手で終局する将棋の50手目から、DBに登録されている手から離れ、実際に思考するとしたら、2倍の持ち時間が与えられているのと同じで、2倍の時間をかけて思考すればR100〜150程度強くなるのは実証されてますから、この分だけ強くなります。


Q) 序盤でのコンピューター将棋側の悪手は思考時間を2倍にした程度では、軌道修正不可能では?

A) 同一変化の棋譜を2度、3度試していれば、それらの局面についての事後検討時間は4倍,8倍のように上がっていきます。そうすればR200〜300、R300〜450のようにそれらの局面でのやねうら王の棋力は瞬間的には(局後検討をした局面では)上がることになります。

少しぐらい不利な局面からスタートしたとしても、未知の局面になってかつ練習将棋のときにくらべて、数手の間だけでもそれだけ強い相手にバトンタッチされれば、勝負の行方はわからないのではないでしょうか。


Q) 残念ながら、指し終わったら電源を切られて意味ないような気がします・・・・。連続対局なら、CPUを学習に割り当てられません。

A) 連続対局であろうと電源が切られようとUSIプロトコルの次のisreadyに対して局後の自動学習が終わるまでreadyokを返さなければいいだけです。それがプロ棋士に貸し出すソフトに対する規約で禁じられているなら話は別ですが、そのへんは私にはよくわかりません。このへんは、設定で変更できるように作っておき、運営の人と話し合って、許される範囲で局後検討機能を有効にしたいと思います。思考設定の変更は思考ルーチンの改変ではありませんから、都度設定を変更するのは許されるかと思います。


Q) readyok返そうが返さまいが電源切られたら(強制終了されたら)学習できないですよね?

A) そこは、DBに保存してあって、次回起動時に局後検討が未消化の局面があるかqueryかけて調べればいいだけです。(局後検討オプションが設定でオンのときのみ)


Q) 局面再現をさせないためなら得した時間をすぐ使ったほうがいいように思うのですが

A) 定跡DBに載っていたので即指しできて30秒得したら、次の手番ですぐにその30秒も加えて思考して、早い段階で研究局面から離れたほうが価値が高いという意味でしょうか。そういう考え方も成り立つと思いますが、統計的に、序盤は思考時間変えてもあまり指し手に変化が出ないのですよね。思考時間が利いてくるのは主に中盤以降ですね…。(よくわかりません。)


Q) やね裏学習メソッドIIなのですが、現実的に正しい敗北対策に収束するのでしょうか…

A) やってみないとわかりませんが、2倍の時間を費やせばR150程度上がるというのは絶対的な真実なので、R150上がった結果、ハマり局面に突入して負けるなら、まあそれは不運としか言いようがないと私は思っています。

コンピューターの苦手な入玉将棋など、思考時間をいくら増やしても全く強くならない展開もありえますが、まあ、それは別の課題でして、やね裏学習メソッドの問題ではないかなと思います。


Q) 電王戦時に貸し出し時と思考設定すら変えられない可能性もあるのでは?

A) 局後の自動検討ですが、その棋譜の全局面を調べなくとも、評価値が傾いた周辺の数手だけでも局後検討する時間があれば全然違ってくると思います。USIのisready(対局準備が出来ているかどうかの問い合わせ)に対して局後検討を続ける設定とは別に、(USIプロトコルの)gameover後、isreadyが送られて来るまでならば局後検討などをしていても許されると思いますし。(これも設定でする/しないを変えられるようにしておこうと思いますが。)



■ 2013/10/16 9:00 やねうら王開発再開!


本日から開発を再開する。まずは3年前のソースコードを掘り起こしてきてVisual Studio 2012でコンパイルが通るようにするところからなのだが…。


実装予定の項目はこうだ。

1) 3年前に仕込んだバグ取り(1日)

2) やね裏学習メソッド、やね裏学習メソッドIIの実装(2日)

3) やね裏定跡の入力(2日)

4) やね裏評価関数のパラメータ学習(2日)

5) 探索部をStockfishのアイデアを元に改良(5日)

1)〜4)が無事終わったら、一応、出場はする。そこまですら実装が終わらなければ残念ながら出場はキャンセルである


■ 2013/10/16 21:30 開発環境整えるのも大変だという話


Windows Server 2012Hyper-Vゲストとして同OSをインストールして、そこでやねうら王の開発をしようと思い、丸一日かけて開発環境を構築していたのだが、以下のバグに遭遇した。


1) Windows Server 2012コマンドプロンプトでの外字の処理にバグがあって化ける。

2) Visual Studio 2012(SP3)のプロジェクト、read-onlyになっているソースファイルに対してコンパイル時にwarningが出る。


以前の開発時には思考ルーチンのデバッグのために外字を使って、コマンドプロンプト上で直接盤面を表示させていたのだが、これが1)のせいで出来ない。Windows Server 2012にもなって誰も外字なんか使っていないのかも知れないが、それにしてもひどいバグだ。このせいで、コマンドプロンプトを使ったデバッグがかなりやりにくい。


2)は自作のプリプロセッサ経由でソースコードを生成していて、その生成されたソースコードを間違えて編集してしまわないように、生成後のソースコードはread-onlyにしているのだが、Visual Studio 2012のバグにより、これに対してwarningが出る。このバグ、Visual Studio 2010のときは、SP2あたりで修正されたはずなのだが、新しいVisual Studioになって、またバグを仕込みなおしたのか。ホント、勘弁して欲しい。


その2点を除けば、とりあえずビルドは出来るようになった。


それから、やねうら王のソースコードはいま確認したら2MB程度あった。泣きそう。このソースコードの詳細、思い出すだけでも大変だ。あと、前回開発時に大改造しようとして、改造しかけた形跡が至るところにあって、思考ルーチンがまともに動かない。revert(以前のバージョンに戻すこと)したほうがいいのだが、きちんと動くバージョンソースコードがどれだかもわからない。仕方ないので明日は、手作業でrevertするところからである


評価関数に変更を加えた場合、学習に2週間程度かかるので、評価関数の変更をするならもう2,3日しか期日がないのだが、ご覧の有様である


■ 2013/10/17 23:00 定跡あり×定跡なしの勝率


定跡DBがないと序盤で思考時間を取られるので、ずいぶん損をする。本家Bonanzaでも、定跡あり vs 定跡なしだと定跡なしのほうはずいぶん負け越すのではないかと思う。

→ 2013/10/18 24:00 試してみました。5分切れ負け100戦。60-2-38。(定跡ありから見て60勝、38敗、2引き分けの意味) 定跡がないとR50〜R70程度低下すると言って良さそうです。

→ 2013/10/19 16:30 さらに100戦。53-2-45。


問題は定跡DBなし×なしの戦いで、これだと同じような戦いばかりになる。並列探索をしているので、まったく同じ指し手にはならないが、似たような進行になる。定跡DBがないと(古いバージョンと)自己対戦によって、改良が正しく行えているかを評価するということすらできない。


やねうら王はいまこの状態で、バグ取りすらままならない。そこで、可及的速やかに定跡DBを搭載しなければならない。明日頑張ろう…。


■ 2013/10/18 21:00 SQLite3導入完了


間々に仕事が入ってくるので、コンピューター将棋の開発に専念できない。今日は2時間ほどしか時間がなかったのでとりあえずSQLite3を導入して、C++から呼び出せるようにした。


SQLite3だがx64用のdllすら用意されて無くて自分でコンパイルするところからやったのだが、x86環境でも動くようにしたい。これを真面目に考えだすと結構面倒である


sqlite3はpublic domainらしいので、sqlite3.cのソースコードプロジェクトに入れることにした。結局のところ、これが一番楽だ。実行ファイルは600KBほど増加した。(Visual Studioソリューションに追加し、sqlite3.cはプリコンパイル済ヘッダーを使わない設定にすればコンパイルが通る。)


速度的には、トランザクション開始〜300バイトほどのテーブル行のINSERT 10万回〜トランザクション終了が10秒かからない。速すぎて驚愕。これなら将棋の対局中にデータを都度INSERTしていき、試合終了時にトランザクションを終了するようにしたとして、終了処理として1秒かからない。


それはそうと、SQLite3用のWindows用の管理者ツール(phpMyAdminみたいなもの)が無くて困った。PHPで書かれているSQLite3用のツールは出来が良いのだが、開発機にPHPの実行環境をインストールしたくないので、単体ソフトウェアとして動作するものを探したのだが、これが、「このソフトはBLOG型の表示ができない」「このソフトは、テーブルのデザインがGUI上で出来ない」「このソフトは、テーブルのダンプができない」など、それぞれのソフトがどこか少しずつ機能が足りていない。複数のソフトを組み合わせてやっとなんとか使える状況である


まあ、今回はそんなに複雑なテーブル設計ではないのでデバッグ作業は問題とならないのでこれで良しとする。


■ 2013/10/19 22:00 npsが知りたいなら実際に探索しちゃいなよ


局後検討のためにそのマシンのnps(秒間の探索ノード数 ≒ そのマシンの探索能力)が必要だ。


これをCPUのクロック数とスレッド数から概算で計算しようと思っていたが、RDTSC命令とか使うと、いまどきのPCはspeed stepとか言ってCPU利用率が低いときに周波数を落とすのでこのへん一筋縄でいかない。CPUのベンダーIDを調べようと思うとCPUID命令が必要なのだが、x64になってVisual C++はインラインアセンブラをサポートしていないのでこの命令を呼び出すだけで一苦労である


結局、システム情報を取得するにはWMI(Windows Management Instrumentation)というテクノロジーを使うのが一番簡単なのだが、このWMI、PowerShellのようなスクリプトから呼び出すのは容易なのだが、C++から呼び出すには一苦労である


仮にそこでCPU名とクロック数が得られたとして、そこからnpsを概算で求めるにはCPU名ごとのnpsが書かれている表みたいなものが必要になる。おい、そんなものどこから用意するんだ。YSSベンチ*1か?


これらのことを考えると、初期局面で実際に探索してnpsを計測するほうがよほど確実で手っ取り早いことがわかる。というか、わかった。今日、数時間も費やしてたったそれだけのことがわかった。泣きそう。


■ 2013/10/20 12:00 いまどきこんなバグがOSに残っているだなんて


Windows Server 2012コマンドプロンプトで外字の表示が崩れると書いたが、外字どころか、2バイト系の記号が全般的に崩れる。(コードページ 932(SJIS),MSゴシックにて確認) printf("□□"); すらまともに表示できない。これのせいでデバッグがままならない。


f:id:yaneurao:20131020122746p:image


いまどき、OSの開発時のテストも大部分が自動化されているのだろうけど、こういう「表示が崩れる」というようなテストは自動テストが書きにくく(そもそも特定のコードページ、特定のフォントで生じる問題であるなら事前にテストが書けない意味もあるし)、テストがザルになっていたりするのだろう。なかなか興味深い事例ではあるが、いまこの状況においてはいい迷惑である


■ 2013/10/20 12:30 将棋所のquit問題


コンピューター将棋のGUIとして将棋所という代表的なソフトがあり、機能性・操作性に優れているので、ほとんどのコンピューター将棋の開発者はこのソフトを用いている。このソフトはUSIプロトコルというプロトコルで思考エンジンとやりとりをする。いまUSIプロトコルはあまり問題ではないので、詳細は省く。


問題は、このやりとりが、標準入出力経由だということだ。つまり、思考エンジンは、printf標準出力に出力し、将棋所からのメッセージはfgetsで取得するようなプログラムにさえしておけばあとは将棋所がなんとかしてくれるという仕組みである


つまり将棋所は、子プロセス(?)で起動させたソフトの標準入出力をリダイレクトしているわけであるが、Windowsではこれは匿名パイプ(anonymous pipe)で行なう。ところがWindowsの匿名パイプはいろいろ仕様が嫌らしい部分があって、子プロセス側でアクセス違反があると親プロセスを巻き込んで落ちたり、その匿名パイプが切断されたときにprocessがkillされたりする(気がする)。詳しく調べていないのでよくわからないが、思考エンジンにバグがあると将棋所を巻き込んで落ちることがあり、大変デバッグがしにくい。


それはそれとして、将棋所では対局後、quitメッセージが送られてくるのだが、そのあとこの匿名パイプが切断されるので、思考エンジンが思考を続けることが原理上出来ない。局後の自動検討は将棋所を使う限りは不可能だ。quitが来る前に自分で別のプロセスを勝手に起動しておけば良いのだが、それはそれで、なかなかお行儀の悪いソフトである


SQLite3は複数のプロセスから同時にDBのファイルをopenすることは想定されていないので、局後検討用のプロセスがこのデータベースファイルアクセスしていると、次の対局の時に思考エンジンがDBにアクセスできない。自前でmutexみたいなもので排他処理をしないといけない。


まあ、それくらいやってもいいのだが、局後の自動検討用のソフトは自前で盤面を表示しないといけない。(しなくてもいいが、するべきだろう) これが大変であるコマンドプロンプトは前述のように表示がバグっているし、また、ユーザー環境に外字をインストールしてもらうわけにもいかない。そうなってくると、HTMLで盤面を出力してそれをブラウザコンポーネントレンダリングするのがお手軽であるが、そういうUIの部分を書きたくないからUSIプロトコルでやりとりをしているのに、本末転倒である


さらに、将棋所には、思考エンジン設定のダイアログテキストボックスチェックボックスボタンなどを表示するための手段がある。(setoptionコマンド) しかし、ボタンを表示してもボタンが押されたときにoptionコマンドが送られてくるのだが、このときに思考エンジン側からinfo string途中経過を将棋所に表示してもらおうと送信しても、それが表示されない。


おそらく、将棋所の作者はボタンが押されたら思考エンジン側は独自のダイアログを出すなりする用途を想定しているのだろうけど、そもそもそういう独自のダイアログとかログ表示ウィンドゥとかを出す手間が惜しいから標準入出力を使っているのであって、ここで思考エンジン側が自らWindowのメッセージループを自分で回して、自分でダイアログを表示して、自分でそこに途中経過の表示をしなさいというのはどうも首を傾げざるを得ない。


info stringではなく、デバッグ用のウィンドゥを将棋所側で出してくれて、そこに表示するためのコマンド(info debugなど)が用意されていないと開発者的には非常に辛い。将棋所はこのGUIを用いて思考エンジンと対局するユーザーには優しい作りだが、開発者には比較的厳しいものがある。


次に、将棋所で対局中に途中中断をするとquitメッセージが送られてくるはずなのだが、中断時にquitを送ると同時にprocessがkillされているっぽく、終了処理をさせてもらえない。前述の匿名パイプが絡んでいるのかも知れないが原因はよくわからない。なかなか開発者的には厳しい作りになっている。


とりあえず、以上のような理由から、将棋所で局後検討を実現するのは現実的ではないという結論に達した。局前検討(isreadyのあと応答を返さずに検討)は出来る。これは通常対局では無意味だが、自動連続対局時には意味があるだろう。また、floodgateに参戦させるときは、対局終了後、すかさず次の対局のためのisreadyが送られてくるので、次の対局までの空き時間を利用して自動局後検討をすることは可能である


■ 2013/10/20 13:45 棋譜からの学習について


とりあえず、やね裏メソッドI,IIの実装と、やね裏定跡の入力は明日ぐらいに終わらせるつもりではあるが、明日で終わるかどうかよくわからない。あと、3年ぐらい前に探索部をいじくりまわしたときの弊害で何やら指し手がおかしい。根が深そうで、このデバッグにどれだけ時間がかかるか想像がつかない。


評価関数はBonanzaの3駒関係から少し変更した。Bonanzaソースをいじって、先週、Bonanzaで棋譜からの学習をスタートさせた。これがまた遅く、DEPTH=3で、4コアのマシン(4年前に購入)だと3万局で1回のイテレーション48時間ぐらいかかる。(2013/10/21 訂正。実際は1イテレーション20時間強ぐらいの模様。) うわぁぁ…。こりゃ、大会当日までに値が収束するかどうかも怪しいな…。


それからさっき、急ぎの仕事が入ってきたので10月22日から4,5日ほど時間が取られる可能性が濃厚だ。こりゃ、下手するとデバッグが終わらんな…。


とりあえずそんな状況のなか、綱渡りのようにしてやねうら王の開発をしている。


■ 2013/10/20 21:20 floodgateの2013年度の棋譜


今日も途中で仕事が入ってきて、1,2時間ぐらいしかやねうら王の開発ができなかった。やねうら王で使う定跡の入力のため、floodgateから棋譜をダウンロードしてこようと思ったら、2013年度分の一括したファイルがなくて、仕方ないからクローラー自分で書くところからだ。


1時間もあれば書けると思うが、本当、思考ルーチンの改良という美味しい部分(?)以外に必要なお膳立てが多すぎて非本質的な作業ばかりが続く。コンピューター将棋に限ったことではないが、こういう地道な作業に耐えられる人だけが優秀な成果を残すことが出来るのだろう。(私には無理だ…)


■ 2013/10/20 21:30 コンピューター将棋の進歩は止まらない?


コンピューター将棋関係者には常識だが、Bonanzaメソッド以降、コンピューター将棋において大きな改良というのはほとんどなされていない。また、探索は従来のコンピューター将棋の探索技術より、Stockfishというコンピューターチェスソフトのほうが優れていることが明らかになったので、上位ソフトは軒並みStockfishの探索部を真似しているような状況である


つまり、いままでのコンピューター将棋における探索技術の歴史の全否定である。(唯一の例外は詰将棋におけるdf-pnぐらいか)


それでもコンピューター将棋の年々の強さの伸びが鈍化したという話は聞かない。

PCのスペックも近年はそれほど向上していないにも関わらずである


これが何故かと言うと、私が思うに、いまのPCで探索深さが十分に深いので、わずかな枝刈り性能の差が決定的な差を産み出すのだ。1手ごとの平均分岐数が2.0なのと2.1なのとではわずかな差に思えるが、しかし20手先を読むときに2の20乗(=1,048,576)と2.1の20乗(=2,782,184)とで3倍近く違う。平均分岐数のわずかな差(枝刈り性能のわずかな差)が、読むべき局面の数として天と地ほどの差を産み出す。


だから、探索深さが十分深くなってきたコンピューター将棋の勝負において、わずかなソフトの改良によって大きく強さが変動するということが往々にしてあり得るのである


このような傾向は、PCが速くなれば速くなるほど顕著になるので、今後は長い時間をかけて統計をとり、改良の効果を毎回丁寧に考察しながら少しずつ改良を積み重ねるというような不断の努力がより一層必要となる。(私には到底無理だ)


■ 2013/10/21 18:00 floodgateクローラー


floodgateクローラー完成。1時間ぐらいかかるかと思ったらC#で書いたところfloodgateでは棋譜が日付別に整理されているようで、ソースコード自体は5分ほどで書けた。うまく動いているようだ。

var start_url = "http://wdoor.c.u-tokyo.ac.jp/shogi/x/2013/";
var dt = new DateTime(2013, 1, 1);
var web_client = new WebClient();
var regex = new Regex("href=\"(.+\\.csa)\"");

// 今日の日付まで達したら終了。
for (;dt < DateTime.Now;dt = dt.AddDays(1))
{
    var url = start_url + '/' + dt.Month.ToString("00") + '/' + dt.Day.ToString("00/");
    var data = web_client.DownloadString(url);
    var mc = regex.Matches(data);
    foreach (Match m in mc)
    {
        var filename = m.Groups[1].Value;
        var url2 = url + filename;
        web_client.DownloadFile(url2, "2013/"+filename);
    }
}

※ 上記のソースコードは自由にお使いください。(実際に動かすときにはサーバー負荷に配慮する処理を追加してください。)


■ 2013/10/22 17:50 1年分の棋譜


f:id:yaneurao:20131023012801p:image


floodgate 2013年分の棋譜は昨日の分までで12万5千局程度。1.5GB程度。ここ数年分だと60万局、6GBほどある。

Windowsファイルシステムだとこの棋譜が入っているフォルダを開くだけでも数分かかる。ファイル列挙をするだけでOSがフリーズ同然になる。扱いにくくてかなわない。プログラムを書くより、待ち時間のほうが長い。ゴミ箱を空にするだけで何時間もかかるのだが…。(Hyper-Vゲストで作業していることや、Shadow Copyによるシステムの復元が出来る設定にしているせいもあるのだろうけど…)


結論的にはこのように大量のファイルを扱うならHyper-Vやめとけとか、ストレージはSSDにしろだとか、そもそもファイルを細切れにせずに1本のファイルにしとけだとか。


プログラムの修正で思い出したが、プログラムの修正の効果を確認するためには5分×200局ほど対戦させないといけないため、丸一日程度要する。それを考えるとこのあとバグ等を修正できるとして2,3個ぐらいだろうか…。


■ 2013/10/23 0:50 CSA拡張プロトコルとはなんぞや


ドワンゴの窓口の人から、メールが来ていて、テスト用のサーバーの準備が出来たから使ってみてね(要約)とのことらしい。CSAプロトコルに独自拡張がされているのだが、ほとんどのコンピューター将棋の思考エンジン開発者はUSIプロトコルに対応させて、ネットワーク接続部分とかは将棋所にお任せなはずで、ここを拡張されても自力では対応できないのではなかろうか…。(しかもあと1週間ほどしかないのに…) 私としては、将棋所で接続できるならそれでいいや。


ところで他の思考エンジン開発者ブログとかTwitterとか進捗がさっぱりわからないけど、もともと思考エンジン開発者は情報とかあまり発信しない文化なのか、それとも、参加申込みをするからにはとっくに完成していていまさら開発進捗も何もあったもんじゃないのか。たぶん後者なんだろう。


■ 2013/10/23 5:00 ドワンゴで用意されている対局サーバーに接続


ドワンゴで用意されたサーバーに将棋所で接続して普通に対戦できることを確認。ポート設定は不要の模様。(ドワンゴの窓口の人のメールにあった4081ポートを指定すると接続できない模様。将棋所がポート設定に対応していないのだろうか?floodgateと同じ4081ポートなので変更する必要はなさそうなだが…)


■ 2013/10/23 5:10 将棋所が勝手に設定を保存する件


将棋所のバージョンが2.8(2013/09/15リリース)以降、思考エンジンの設定が勝手に将棋所に保存されるようになった。これによって便利になるソフトもあるかも知れないが、ほとんどのコンピューター将棋ソフト開発者にとっては迷惑極まりない。


なぜなら、ほとんどの開発者は、思考エンジンデバッグ用のウインドウなどを出すようには作っていない。USIプロトコルに対応させるためには標準入出力の処理だけで済むため、それ以上のことをしようとは思わない。つまり、思考エンジンデバッグコマンドラインから行なっている。このときに毎回setoptionなどをコマンドラインから手打ちするのは嫌だから設定は自前で保存し、思考エンジン起動時に自前で読み込むようにしている。ほとんどの開発者はたぶんそうしている。


将棋所が単に思考エンジンからのoption設定を二回目以降無視するだけなら良いが、将棋所の思考エンジン設定で設定を変更してもその変更をsetoptionで通知せずにquitコマンドが送られてくるので、思考エンジン側では将棋所の思考エンジン設定で変更された設定を保存する機会が与えられない。(通常対局の最初に送られているので一度でも対局すればisreadyが来たタイミングで保存することは出来るのだが、上で書いたように中断ボタンを押したときにquitが送られてくる前にkill processされるようで、終了タイミングでは保存できない。isreadyタイミングで保存しなければならない。なんてことだ…)


また、開発時には設定項目を増やしたり減らしたり、設定のデフォルト値を変更したりするので、都度、将棋所が書き出している設定ファイル(Engine.xml)を削除しなければならない。そもそもこのファイル、勝手に消していいのか?副作用はないのか?など、不安の種は尽きない。


これらの理由から、設定が将棋所で保存されるメリット開発者的には皆無で、デメリットしかないという状況である



■ 2013/10/23 5:20 将棋所にデバッグウインドウが欲しいのは私だけではないはずだが


将棋所に言いたいことはいくらでもある。例えばデバッグ表示である。USIプロトコル対応の思考エンジンである以上、局面をUSIプロトコルに書かれた局面形式で出力する処理はどの思考エンジンであってもすでに書いてあるはずである


よって、デバッグ時にこの形式で局面を出力して、それが将棋所側で用意されたデバッグウインドウに局面が表示できれば開発がすこぶる捗ることは間違いない。


将棋所側でデバッグ用の局面表示に対応するのは難しくないと思うのだが、将棋所の作者は思考エンジンを作っている人ではないらしく、(思考エンジン開発者ではなく)将棋ファンのための利便性のほうに力点があるようで、そういった意見はなかなか受け入れられない。


とは言え、USIプロトコル対応のGUIで連続対局・CSA対局サーバーへのネットワーク接続などの機能がひと通り備わっているUSIクライアントは将棋所しかなく、実質的に将棋所一択のような状況である。また長年の動作実績があるので通信対局など重要な部分においてバグはほとんどないと思われる。これと同じクオリティでUSIクライアントを作ろうと思うと数ヶ月単位の大仕事である。(主要部分だけなら1ヶ月もかからないかも知れないが) このため、なかなか自分で作る気にはなれない。


■ 2013/10/23 7:15 floodgateの棋譜が使い物にならない件


やね裏定跡の分析のためにfloodgateの棋譜をふるいにかけるプログラムを書いたのだが、floodgateの棋譜(CSA形式のファイル)には評価値がついていない。そんな馬鹿なと思って、サイトのほうで対局画面を見ると、評価値グラフというのが表示されている。この評価値グラフはどこから取得されているのかと思ったら、別途、どこかからSVGで流し込まれているようだ。(GnuPlotを使ってあるからか?)


よくは調べていないが、このSVGのデータソース元は公開されていないようで、SVGファイルから元の評価値を復元するのは実質的には不可能だろう。何故、ソフトの評価値という指し手とともにサーバーに送っている一番大切な情報をCSAファイルに書き出さないのか、この実装には頭を傾げざるを得ない。この実装だと棋譜の二次利用をする上で非常に困るし、ひいてはコンピューター将棋の進歩を妨げる。


対して、floodgateではソフトの読み筋として送っている情報は、CSAファイルに「'**」として書きだされているのだが、この読み筋を送るかどうかはソフトに委ねられているので送ってこないソフトは送ってこないし、しかも投了の瞬間には評価値も読み筋も送らないので評価値的にマイナスになったから投了したのか、それとも途中中断等の操作により投了したのかCSAファイルから判断がつかない。


CSAプロトコル上は投了の直前にも評価値を送れると思うのだが、将棋所が送っていないからか、投了時の評価値はCSAファイル上には記録されていない。2手前のそのソフトが送信した評価値(CSAファイルに記録されている)を見ればどちらが優勢だったかはわかるはずだと言う人もいるかも知れないが、将棋には、優勢だと思っていたのに着手された瞬間見落としていた即詰みに気づき投了することがある。


コンピューター将棋でいまどきそんなことってあるの?」と思う人もおられるだろうけど、実際に上位のソフトでもこれは稀にある。例えば、次の習甦 vs Blunderの対局である


f:id:yaneurao:20131023071455p:image

http://wdoor.c.u-tokyo.ac.jp/shogi/view/index.cgi?csa=http%3A%2F%2Fwdoor.c.u-tokyo.ac.jp%2Fshogi%2Fx%2F2013%2F05%2F03%2Fwdoor%2Bfloodgate-900-0%2BShueso%2BBlunderXX_Q6700_2c%2B20130503033005.csa&move_to=&move=last


投了直前までBlunderは自分が優勢だと思っており、習甦が8一角を打った瞬間に負けに気づき投了している。評価値グラフ上は一度たりとも劣勢である値は出力されておらず、CSAファイルはもちろん、グラフを見てもBlunderが勝ったのか負けたのか、そして局面が優勢だったのか劣勢だったのか、判断できない。


floodgateの棋譜はコンピューター将棋開発上も、また将棋の文化的にも、重要な遺産であるから、こうした問題をきちんと解決してもらいたいと切に願う次第である


※ ちなみに上の局面からの詰み手順は、8一同玉に7ニ銀!である。(9ニ玉と逃げると9三香、同金、同角成、同玉、8三金からの詰みがあるので、7二銀には同玉だが、6ニと、8一玉、7ニと、9一玉に9ニ金、同玉、9三香、同金、8ニ角成以下詰んでしまうのである) この7ニ銀〜6ニとの手順はいかにも効率が悪そうなのでBlunderは通常探索で見落としていたのだろう。



■ 2013/10/23 9:30 互角のソフト同士が100局対局してどこかで10連敗する確率は?


ソフトの改良の結果、強くなっているかどうかを試すのは将棋所などを用いて200連戦ほどして、統計学的に有意かどうかで判定する。ところが、同等になるはずが、初っ端から何連敗もすることがある。「でも長期的には勝率五割に落ち着くんでしょ?それって確率的には…」みたいな話をいまからしたいわけじゃない。


将棋所で1つ目に登録する思考エンジンのほうが、最初、少し分がいい気がする。最初の10回ぐらいに関しては1つ目の思考エンジンのほうが有利ではないかと思う。


もちろん、片側の思考エンジンが思考しているときにもう片側の思考エンジンの待機のさせかたが悪く、CPU資源を幾ばくか食っているだとかそういう初歩的な問題ではない。また、人間の感覚的に最初に起きた事象ほど印象深く残っているだとか、そういう感覚の話がしたいわけでもない。


では何かというとOSのスレッドスケジューリングの問題である。OSのプロセス/スレッドスケジューリングがどうなっているのかについては、一言で言うと謎であるWindows7と8とで何かアルゴリズムに変更が加えられていてもそれを知るのは並大抵のことではない。(OS開発者が自分で記事にするだとか、ソースコードが流出するだとかしない限り)


それで、思考エンジン1の(OSの処理単位としての)プロセスおよびスレッドのほうが思考エンジン2のプロセスおよびスレッドより先に作られる。それも、コア数だけ並列化するので、4コアなら最低でも4スレッド。場合によってはHyperThreadingを考慮し8スレッドを生成する。


ところが、そんなに作って、それらのスレッドスレッド負荷率100%でぶん回したときにOSはこのスレッドをどう捉えるのだろうか。大仕事が来たから、他のプロセスにはちょっと待ってもらおうというようなスケジューリングがなされないだろうか。


ファイルシステムなんかでもそうだが、一つ目のファイルの転送が終わらないうちに2つ目のファイルの転送を始めるとすこぶる転送速度が落ちる。このようなことを考え、関係のありそうなプロセスに関しては、なるべく先に起動されたプロセスを優先するようなスケジューリングをしてもおかしくはない。


その結果、思考エンジン1のほうが思考エンジン2よりCPU資源等において優遇されてもおかしくはないのである


…ということをちょっと思ったが、たぶんそんなことはないんだろうな…。

(私は気になるので連戦するとき、半分の対局数を消化したところで思考エンジン1,2を入れ替えているが…)


■ 2013/10/23 20:55 コンピューター将棋の改良点 2013年度版



コンピューター将棋の探索はコンピューターチェスのStockfishのパクリ手法を真似て行なうというのが決定打であることはすでに書いた。


また、高速化に関してはどうせメモリ帯域がボトルネックになるのでそれほど劇的な高速化は不可能で、プログラミング経験30年以上の大ベテラン(?)が書こうと、プログラミング経験15年程度のひよっこ(?)が書こうと数割程度の速度差しかないのが現実である


そもそも上位に君臨しているコンピューター将棋の思考エンジンを開発している人たちのほとんどは東大関係者で、かつプログラミングスキルに非常に長けている人が多いので(C++ templateを自在に扱え、x64やAVXなどのアセンブラに精通し、CPUアーキテクチャを詳細に理解しているので)、そういう前提で話をするなら「(そのクラスの人間ならば)誰が書いても速度は同じ(せいぜい1,2割程度の違い)」と言っても過言ではない。


そうなってくるとコンピューター将棋で劇的な改善があり得るのは評価関数と定跡部分だけなのである


定跡部分の劇的な改良として、対局中/対局後の自己学習(やね裏メソッドI,II)および、詰みまで入力された定跡(やね裏定跡)については、私が考案した。(コンセプトプルーフのためにも、多少バグってようが、弱かろうが、今回はなんとしても出場したい。)


そして評価関数なのだが、Bonanzaの三駒関係でもまだ学習方法(ボナンザメソッド)の改善は十分に考えられる。まだいまの機械学習では三駒関係すらきちんと学習できていない部分が多々あり、それらを改善することによりまだ強くできるのである


そうは言ってもボナンザメソッドでもそこそこいい値に収束しているので従来、これで十分だと考えられていた。


ところが、PCのスペックが向上し、また探索技術としてStockfishのものをパクリ取り入れ、探索が効率的に行えるようになってきたので、わずかな評価値の差が勝率の差として大きく反映するようになってきたのである


つまり、わずかにボナンザメソッドを改良するだけで勝率が数割あがる(例えばNDF)というのは普通に起こりうるわけである


(つづく)



■ 2013/10/23 21:00 評価関数の棋譜からの学習の改善方法


評価関数の学習メソッドの改善方法はいくつかある。機械学習の手法そのものをボナンザメソッドから変更する。例えば、収束の速い方法(オンライン学習等)にするだとか。


しかし、そうしても収束が速いか遅いかだけの違いで、強さとはあまり関係がない。むしろ、オンラインは収束は速いが値の精度がよろしくないので三駒関係をオンライン学習でやったときにボナンザメソッドよりいい値に収束するかは私には疑問である。(というか、私はよく知らない。)


そこで、目的関数(良い手だと定義し、その良い手が大きな値になるように設計された関数)をどう設計するかという話になる。


棋譜が教示信号なわけであるが、なるべく良質な棋譜を大量に集める必要がある。(棋譜の数が少ないと実戦例に乏しい形をきちんと学習できない)


いまであればプロ棋士コンピューター将棋との実力が拮抗していることが示されたので、floodgateの棋譜を使うのも悪くないと思う。


また、棋譜の良さに応じて重みづけを変えてやるという手法は古くからある。


試合に勝ったほうの指し手のみを学習するだとか、強い棋士の重みは大きくするだとかである


私が採用したアイデアは、トップ棋士である羽生さんの指し手は重みを2として、底辺棋士の重みは1とし、棋士レーティングに比例した重み付けをするというものである。(以下、その正規化されたテーブル) また、これを用いて三駒関係を学習させたときに勝率が有意に改善されることは確認した。


// 棋士の名前と、正規化されたレーティング
char* kishi_name[] =
{
"羽生善治三冠",
"渡辺明竜王",
"郷田真隆九段",
(中略)
"佐藤義則八段",
"安西勝一六段",
"上記以外の棋士",
};

double kishi_weight[] =
{
2,
1.934023286,
1.857697283,
(中略)
1.07373868,
1.067270375,
1,
};

他の手法として、例えば、対局中の評価値の推移のように2手進めてみると前の評価値が過小/過大評価であったと気づく場合がある。(下図) 要するに深い深度での探索結果と浅い深度での探索結果とが一致するようにパラメーターを修正という考え方がある。これはBlunderなどで採用されている。(NDFもこの考えかたなのかどうかについてはNDFのアルゴリズムの詳細が発表されていないのでわからないが)


f:id:yaneurao:20131023211343p:image


ともかく、「コンピューター将棋には興味があるけど、自分で探索部も詰将棋ルーチンも指し手生成も書きたくないよ!(書けないよ!)」という人は、どうせ評価関数こそが最大の肝であるので、この部分の改善をしてコンピューター将棋界にデビューするのもアリなのである


そして、上で書いた通り、評価関数以外の部分ではほとんど改善がしにくいのが実状なので、評価関数の改善だけに取り組みつづける人が成功する可能性が案外高いのである


■ 2013/10/24 17:30 やね裏定跡、11,875局分入力完了!


やね裏定跡(詰みの局面まで入力された定跡)の11875局分の入力が完了した。

(入力って言っても私が手打ちしたわけじゃなくて、プログラム書いたあと放置してただけなんだけど…)


SQLite3は結構速く、各局面での最善手およびその指し手の出現頻度を保存していく場合、秒間数局(300query/sec)程度はさばけるようだ。(Hyper-Vのguest OSでそれくらいの速度なのでSSDを載せてある最先端のPCならその何倍も出ると思う) ただ、局面数が増えてくると(DBのファイルが大きくなってくると)だんだん遅くなって…スケーラビリティは今ひとつかも知れない。


まあ、それでも秒間50queryぐらいできるから、1手ごとに定跡DBに問い合わせたり、試合中に思考結果をDBに書き戻したりするのはどうってことなさそう。ただ、欲を言えば本番ではHDDよりはSSD搭載のPCのほうが嬉しいのだが…定跡DBをSQLite3のような汎用DBを使って実装している将棋ソフトは他にはあまりないだろうから、そういう要望はあまりないんだろうなぁ…。


また、SQLite3を使った定跡DBの構築作業は、非常に楽だった。Bonanzaの定跡処理部分のソースコードとか二つの定跡ファイルマージするための処理とかが書いてあって、結構複雑だった記憶があるが、SQLite3ならそういうことは一切考えなくて済むし、あとでテーブル設計を修正するようなことも容易である。本当、SQLite3を選択して良かった。Bonanzaみたく自前のDB構造でやってたら私は今月いっぱいかけても定跡DBが完成するかどうかすら怪しいところだった。


なんにせよ、やね裏定跡の用意が間に合って良かった。ちょっと動作が怪しい部分もないではないが…。

もう少し改良してみることにする。

→ やね裏定跡を厳選しなおした結果3734局に減ってしまった。


■ 2013/10/24 18:45 やね裏定跡とは何なのか?


やね裏定跡とは何なのか?


Bonanzaなどに入力されている定跡は精度が悪く、定跡を抜けた時点で劣勢の局面であるということが多々あった。いまやコンピューター将棋はそこそこ強いので、そのあとfloodgateのように15分の持ち時間で終局まで続けると一度も劣勢の評価値にならないままゲームが終局する可能性が高い。


つまり、このとき次のような評価値曲線を描く。


f:id:yaneurao:20131024185006p:image


これを「ワンサイドゲーム」と定義する。このワンサイドゲームでは、定跡を抜けたところでプラスの評価値であることが保証されており、また、双方のソフトがそれを同じように評価していること、そして、そのあと実際に勝っていることからも、定跡を抜けた局面ですでに優劣がついている可能性が高いと考えられる。


そこで、上記のようなワンサイドゲームを信頼できるソフト(R2800以上のソフト)に限って抽出し、その勝ったほうの指し手のみを定跡として入力した。それがやね裏定跡の正体である


こうしておくことで定跡を抜けた局面で自分が有利になっているようなゲーム木(定跡木)が得られる。


従来、定跡木の終端局面それぞれでBonanzaを何秒か思考させて、定跡木のなかでmin-max探索のようなことをして有利になりやすい定跡を選択するような研究があったと思うが、やね裏定跡は、それと同じような効果が得られるわけである


■ 2013/10/25 18:45 お手軽な思考時間制御法について


コンピューターチェスコンピューター将棋の思考時間制御は非常に難しい問題で、真面目なアプローチとしては、局面がどれくらい不安定か(正しい判断を下すために思考時間の必要な局面であるか)をたとえばSVM(サポートベクターマシン)で数値化して、それに応じた時間を費やすのが望ましい。


ところが、そういうアプローチは大変面倒くさく、手間がかかるので、普通の開発者はそこまでやっていない。やっていないながらもお手軽にそれらしくする方法をここに書いてみたい。


まず、将棋の序盤はどうせ考えても致命的なほどの差はつかないゲームなので、中盤の思考時間の半分だけ使うとする。そして終盤もそこそこコンピューター将棋は正確に読むので終盤も徐々に思考時間を減らすとする。この関数をaとする。


そうすると、関数aをグラフに書くと下図のような台形になる。


f:id:yaneurao:20131025184028p:image


いまN手目で、ここでの残りの手持ち時間は思考ルーチンにUSIプロトコルで与えられる。切れ負け設定であれば、これが緑の部分の面積Sに相当する。このN手目で使っていい時間は、NからN+1までの小さな縦長の台形の面積である


よって、斜線の面積をSoとすると、今回の思考時間 = So / S × 残り持ち時間 みたいな式になる。(SoととSは、関数aを積分して出すものとする)


個人的な見解だが、重要な局面でだけ他の局面の何倍も深く読んでもなかなか効果が出にくい。その前後の局面もそれ相応に読むべきである。例えば詰将棋で最初に時間を費やし13手詰めを読み切り、初手で飛車を捨てる手を指したが、次の手番で9手しか読まなかったらどうだろう。詰みまで読みきれずに日和ることになり、前の飛車を捨てた手が致命的な悪手となってしまう。


よって、読みを特定の手だけ増やしてもさほど効果はないのではないかというのが私の考えである。(その手の前後もある程度増やして、上図の台形のように、なだらかに持ち時間が1手ごとに変化するようなものが理想だと思う)


■ 2013/10/26 02:30 Bonanza系の探索ルーチンでは本大会では上位に食い込めない?


Bonanza系の探索ルーチンを搭載しているソフトは多コア(6コア以上)になったときに、(他の将棋ソフトに比べて)探索性能が出ないようである


本大会のように8コアのPCでかつ、統一ハードだとBonanza系の探索ルーチンは圧倒的に不利なのだ


やねうら王もご多分に漏れずBonanzaソースコードを大いに参考にしているのでモロに煽りを食っている。だからStockfish風に探索部を丸ごと書き換えたいのだが…。


まあ、やねうら王の場合、それ以前の問題として、まだ評価関数の学習が終わってなくて、あと、やね裏学習メソッドI,IIの実装が終わってなくて、おまけにいくつかバグがあって、ときどき変な指し手が混じってるんだけど…。それでも、まだ直したいところがあるのでこのあとソースコード大量に書き換えるつもりでいるのだが、テストすらろくに出来ない可能性が…これで出れるのか…。いや、出るけど…。


ちなみに対Bonanza6.0、現在の勝率は40%ぐらい。(変な指し手で自爆して勝てない局が混じってる) おい、頼むよ。せめて5割は勝ってくれよ…。というか、nps(探索速度)とか、改良内容からして7割ぐらい勝たないとおかしいだろ、これ。


嗚呼、テイルズオブハーツRさえ出ていなければ…。こんな大事な時期になんて大作ゲームを出してくれやがるんだ!テイルズの大ファンとしてはやらざるを得ないじゃないか。くそ〜!


■ 2013/10/26 13:00 持ち時間制御その2


持ち時間について、いまルールを読んで知ったのだが、


1) 電王戦トーナメントの予選は、持ち時間15分+そのあと1手10秒

2) 電王戦トーナメントの本戦は、持ち時間2時間切れ負け

3) 電王戦(プロ棋士との対局)は、持ち時間5時間+そのあと1手1分


となっているようである。正直、切れ負けの調整しかしてなかった。

切れ負けも15分切れ負けのつもりで調整していた。いまから1)〜3)を書かないといけない。


コンピューター将棋は持ち時間の使い方によって勝率は大きく変動する。やねうら王の場合、やね裏定跡にハマると序盤で有利になるので中盤でBonanzaの2倍ぐらい湯水の如く時間を使い、そのまま終盤を押し切るという作戦で考えていたが、上記2)のように2時間も持ち時間があると、floodgateの棋譜通りにいかないから、序盤で互角以下で進行し、中盤で時間を使ったわりに互角のまま進行し、終盤、時間がなくて大きく弱体化して負けるという最悪の流れとなってしまう。


やねうら王としては本戦、こんなに時間要らないのに…(ノ∀`)アチャーという感じである

やはり、上記2)のために持ち時間の使い方を調整しなおさなければならない。


次に、1)と3)だが、この1)と3)でアプローチの仕方が全く異なる。


1)は、持ち時間とそのあとの1手の時間との比率が90 : 1であるが、3)は、300 : 1である。前者であれば、100手目(自分の手番は50手)までに持ち時間を使い切り、そのあと1手ごとに9.8秒ぐらいまで使うのがベストであろう。(そんなギリギリにして通信のレスポンス的に大丈夫なのかどうかは知らんが…)


3)は、持ち時間とそのあと1手とのバランスが極めて悪いため、使い切る戦略にすると終盤の思考時間が相対的に少なすぎて、終盤で相当の弱体化をしてしまう。おそらく使い切る戦略は損だと思う。これくらいのバランスならば140手目ぐらいまでで持ち時間を消費するぐらいのペースで進めて、そのあと持ち時間がなくなれば仕方ない、というぐらいの配分がベストではないかと思う。


と、このように、

・切れ負け(持ち時間がなくなると負け)かどうか

・持ち時間と1手ごとの時間との比率がどうである

という二つの観点から最適値というのは変わってくるのである。つまり、上記の1),2),3)ではそれぞれ全く異なった持ち時間配分のための戦略が要求されるのである


いまからこのプログラムを書いて調整しなければならない。

やね裏学習メソッドの実装もまだだというのに…。それ以前にバグ取らないと…。




■ 2013/10/26 21:30 思考時間制御がすべての鍵


探索部をどう改良してもStockfishから劇的に改善されることはないのが実状。

また評価関数もどう改良してもBonanzaの3駒関係から劇的に改善されることはないのが現実。


それに対して、思考時間制御(思考時間の配分の調整)というのは、劇的な改善をもたらす。重要な局面を判断して、そこでのみたくさんの時間が使えるなら劇的に強くなる。


そのことに私が気づいたのはだいぶ後であって、Blunderのaki.さんから、「大学の卒論のためにコンピューター将棋の思考時間制御について研究しようと思っている」という話を聞いたころ(5年ぐらい前の話)まで遡る。


当時はもとより、いまでも思考時間制御なんてほとんど誰も注目していない分野であり、また、そこを改善したところで…みたいな考えもあって、当時の私は「aki.さんなら、評価関数とか探索とか研究したほうが実りがあるんじゃないですか」とどっちかというと否定的な見方をしていた。


しかし思考時間制御にボナンザメソッドを導入して、なおかつ成果を挙げたaki.さん。その画期的な論文に、私の名前が載っている*2のは身に余る光栄である


■ 2013/10/26 21:35 最終局の直前までが俺の開発期間だ!


今日は私の誕生日だったので祝賀会でこんな時間になってしまった。開発する時間がどんどん減っていくな。こりゃ、電王戦トーナメント中にも開発せざるを得ない。


大会規定では、(5位以内の入ったとして)電王戦トーナメントに出場したソフトを無改造でプロ棋士と戦うことであるから、電王戦の最終局まではプログラムをいじっても構わないことになる。(最後の1局でその最終調整をしたソフトを用いるなら)


昔、YSSの山下さんが世界コンピュータ将棋選手権で本戦の前日とかにホテルプログラムをいじっていたという話を聞いて、「そんなときにいじってエンバグ(修正した結果、新たにバグを生み出してしまうこと)でもしたらどうするんだ」と思ったものだが、大会中、それも最終局の直前までVisual Studioを起動してビルドしていたという前例はないはずだ。私がその記念すべき第一号となろう。


者ども、俺様の生き様(死に様?)を見ておれ!


■ 2013/10/27 18:45 やね裏学習メソッドIの実装完了


テストはろくにしてませんが、とりあえずやね裏学習メソッドIの実装が完了しました。


実装自体は簡単なものの、将棋所の思考エンジン設定のところから様々な学習オプションを変更できるようにしたり、その設定されたオプション通りに動くようにしたり、説明用のドキュメントを更新したりと、何かと時間がかかります。


一度指したことのある局面をさくさく指してくれると人間側としては対局していて非常に気持ちがいいですね。まあ、今回の大会ではあまり関係ないかも知れませんが。


とりあえず1局ごとに定跡を学習するのは世界初だと思ってたのですが、よく考えたら1985年ごろに棋太平という将棋ソフトがあって、あれも序盤の自分(コンピューター)の指し手をDB(?)に記憶してたような気が少しします。持ってなかったので良くは知りませんが。棋太平はソフトコピーすると、プロテクトに引っかかっていると起動画面の馬に跨っている武士が馬から落馬している画像に差し替わるのが有名ですね。


まあ、なんにせよ、コンピューター将棋で1局ごとの局後の自動検討〜自動学習はやねうら王が世界初ですかね。


■ 2013/10/28 1:35 やねうら学習メソッドII実装完了


やね裏学習メソッドIIの実装も完了しました。もう眠たいのでテストは明日やります。


やねうら学習メソッドI、やねうら学習メソッドIIのために書いたソースコードはそれぞれ300行程度。あと、本体のソースコードの修正が必要だった箇所が200行程度。そんなわけで今日は1100行ほど書きました。


SQLite3を使っているのでDBアクセスまわりはすこぶる楽ちんです…が、局後検討のため思考エンジンをDBから読み込んだ指定局面から呼び出す必要があるのですが、その部分のソースコードは、あまり綺麗に書いていなかったので意外と大改造になりました。


実際はソースコードを書く何倍もの時間を検証作業とかドキュメント作業とかに費やさないといけないので明日以降、時間がいくらあっても足りません。よくこんな状態でエントリーしたなぁと自分でも思うのですが。


■ 2013/10/28 1:45 スレッドまわりが複雑


やねうら王のスレッドまわりですが、以下の4グループにわけられます。


1) USIコマンドの受付スレッド

2) 思考時間を監視して、時間になったときに強制停止させるためのスレッド

3) 思考ルーチンの開始〜終了のために待機しているスレッド(思考開始時は、このスレッドが思考ルーチンのメインスレッドとなる)

4) 思考ルーチンのスレッド(コアの数だけ)


という構成になっているのですが、DBにどのスレッドからアクセスすべきかだとか、思考スレッドとの調停をどのスレッドが行なうべきかだとか、そういう問題が出てきて、極めて複雑な状態管理が必要になります。


図を描いて状態遷移などについて説明すべきなのですが、いまはその気力がありません。すみません


上記2)みたいなものを作らなければ設計は楽になるのですが、正確に秒読み時間のギリギリ(0.97秒ぐらいまで)使いたいので、そのためにはどうしても残り時間を監視するための専用スレッドが必要になります。


■ 2013/10/28 1:50 当日までにやるべきこと


現時点でのToDo。


・やねうら学習メソッドI,IIの動作検証(バグがないか)

Visual Studio 2012を当日持っていくノートパソコンにもインストール

・持ち時間制御のための手法を考えなおして、実装

・探索がおかしいバグ修正(たぶんかなり根が深い)

・条件を変えながらBonanzaと対戦実験&チューニング

・やね裏定跡がBonanza相手にハマるパターンを調査

・当日までにボナンザメソッドで棋譜から学習させている評価関数パラメータがいい感じの値に収束してくれることをお祈り


間に合うのかなぁ…。特に探索がおかしいバグは…どうだか…。


■ 2013/10/28 1:55 Bonanzaのnarrow book問題


この記事自体が長文すぎて誰もこんなところ見てないとは思いますが、Bonanzaのnarrow book問題について、ちょっと走り書きだけしておきます。


narrow bookというのは定跡DBを使うとき、出現頻度の高い定跡のみを使うというオプションです。


やねうら王もこのアイデアに倣い、思考エンジン設定でnarrow bookのオプションが用意してあり、出現頻度の高い定跡のみを採用することが出来ます。


それでBonanzaと対戦させていてわかったのですが、Bonanzaのnarrow bookでないとき(たぶんデフォルトではそうなっている)は、不利になる定跡が混じっています。プロがたまーに趣向として指すような、アマチュア臭い感じのアレですね。


早い話、narrow bookにしないとBonanzaは弱いんですね。今日、Bonanzaと対戦させてて、200戦して5割以上勝つなーと思って眺めていたのですが、なんのことはない。narrow bookをオンにするとボコボコ(死語)にやられました。3,4割ぐらいしか勝てません。あまりに凹んだので、50局目ぐらいで対局を中断しました。


やねうら王の探索がバグっているのか、もともと探索部がおかしいのかはよくわかりません。

また、持ち時間設定によって勝率ががらっと変わるので、何を基準にしていいのかさっぱりわかりません。持ち時間によってはBonanzaに7割ぐらい勝てたり、3割ぐらいしか勝てなかったり。対戦結果にムラがありすぎですね。


やねうら王の持ち時間の使い方が悪いのもあるんでしょうけど。

とりあえず、この問題をあと残された期間中に解決しなくてはならないのです。


まあ、そんなわけでBonanzaは当日はnarrow bookで来るんじゃないかなーと思うのですが、それならそれでnarrow bookに対してやね裏学習メソッドIIで事前学習させたいわけですが、まあ…いまからでは到底無理ですね。大会に出てくるBonanzaBonanza 6の定跡ファイルのままとは限りませんし、局後検討に要する時間は半端ないですし。


そういう意味ではやね裏学習メソッドは今回、完全に空振りなのですが、まあ面白ければそれでいいじゃんと言いますか、とりあえず、こういうアプローチが可能なのだということを他のコンピューター将棋の開発者の方に知ってもらえればと思います。



■ 2013/10/28 2:20 長文になってきたので次ページに


次ページ。


電王戦 --- 将棋電王トーナメント --- やねうら王特設ページその2

http://d.hatena.ne.jp/yaneurao/20131028#p1

kanokekanoke 2013/10/13 09:03 きた!期待してます!って全然できてないんですかい…。
NHK杯で渡辺さんが初戦敗退したり、最近将棋が面白い。

かず@Calamityかず@Calamity 2013/10/13 11:17 ついにやねうら王がベールを脱ぐわけですね!
恐怖しつつ、期待します。

yaneuraoyaneurao 2013/10/13 15:58 ↑*2 あ、世界最速の指し手生成ルーチンはできとります。その他の項目はこれからです。あと、数年前に仕込んだバグを修正するところから…。
↑*1 1週間程度でどれくらい強くなるかは…。

かず@Calamityかず@Calamity 2013/10/14 22:07 やねさんはゲーム作りのプロですし、凄いGUIで参加されるのでしょうか?そっちも超期待してます!

yaneuraoyaneurao 2013/10/15 09:08 ↑私にはあと6日ほどしか時間がないので思考ルーチンの改造させてくださいよ!ヽ(`Д´)ノ

wainwain 2013/10/15 22:17 Q&A分かりやすいですね。
頑張ってください。
電王戦時に貸し出し時とオプションすら変えられない可能性もあるので気をつけてください。
あと今回は出ませんがやね裏学習メソッド(定跡自動学習)のアイデア流用させていただきます。

kanokekanoke 2013/10/16 09:49 一生懸命作ってたら締切過ぎてて「あれ?締切今日じゃなかったの?」ってなりそうな気がする

usapyonusapyon 2013/10/18 15:04 芝浦将棋が定跡無しで定跡ありのBonanzaに56%くらいの勝率じゃありませんでしたっけ?
(もっとも芝浦将棋自体、BonanzaからTD−λで学習して強くなっているはずでしたが)

yaneuraoyaneurao 2013/10/18 21:09 ↑いまテストのため5分切れ負けで100局ほど対局させているところですが、途中経過は47-1-35ですね。定跡がないと勝率が42%前後(R50程度弱体化する)ということですかね。

やねうら王応援してますやねうら王応援してます 2013/10/19 09:46 やねうら学習メソッド?のことが、プロ側に伝わっているとしたらですが。プロ側は、事前研究の中で勝ちが確定したところで投了してしまうことで学習されることを防げるのでは?

yaneuraoyaneurao 2013/10/19 10:38 ↑まあ、あり得るでしょうね。相手が投了しても局面の評価値が大きくマイナスであれば局後検討の処理をしたほうがいいのでしょうね。

wainwain 2013/10/20 00:05 もう求めて無い情報でしょうがVisual C++からCPUID見るなら__cpuid組込み関数が一番楽かと。

yaneuraoyaneurao 2013/10/20 02:12 ↑情報ありがとうございます。組み込み関数であるんですね。いま調べたら、rdtscも組み込み関数であるようです。なるほど…。

piro77piro77 2013/10/20 23:01 やねうら王は常駐サーバサービスみたいにしては?。将棋所からはやねうら王と通信するだけのプログラム作るとか。時間もないのに面倒すぎるか・・・

yaneuraoyaneurao 2013/10/21 00:14 ↑そこまでするとなるとついでに自動でクラスタリングが組まれるところまでやりたくなりますねー。いずれやりたいとは思ってます。

かず@Calamityかず@Calamity 2013/10/23 02:21 拡張プロトコルはfloodgateで使っているshogi-serverで拡張されたプロトコルです。%%WHOコマンドでx1が付いていれば拡張プロトコルでログインしています。
で、状況ですがまだビルドが通っていません(汗)。

yaneuraoyaneurao 2013/10/23 03:03 ↑回答ありがとうございます。そうなんですね。とりあえず、将棋所で対戦できるなら私としては無問題です、はい。

ぽぺぽぺ 2013/10/24 01:12 がんばっても1〜2割しか改善しないのであれば、むしろ相手の思考を阻害するような手を採用した方がいいのでは?と思ったり。
「最適な手」より「ちょっと最適じゃないけど相手をかく乱する手」とかの方が実際は良かったりするんじゃないでしょうか。

というか、コンピュータvsコンピュータの場合は、相手のCPUリソースを無駄に使わせるような手にしたら、それだけで相対的にこちらが強くなったりできないんでしょうか?
まぁ、そんなのは難しいんでしょうね・・・

yaneuraoyaneurao 2013/10/24 01:35 > 相手のCPUリソースを無駄に使わせるような手にしたら

まず、狙ってやれるかという問題がありますが、仮に狙ってやれるとして、相手のCPUリソースが無駄になるかどうかの判定が必要になって、その判定のためのコストは相手に無駄にさせるCPUリソースをはるかに上回るような気がしますね。

コンピューターによる指導対局で、人間相手にわざと人間が読みにくい(平均分岐数が多いだとか駒と駒が激しくぶつかるだとか)局面に誘導するのはわりかし昔からある研究ですね。

makmak 2013/10/24 03:30 floodgateの棋譜の評価値はコメントの最初にありますよ
'** 255 -6273OU +8685FU -5263KI

yaneuraoyaneurao 2013/10/24 04:34 ↑そのコメントを送るかどうかは、USIクライアント側に委ねられているので送っていない設定にして参戦しているソフトが結構あるのです。

また、本文にも書きましたが、送っていても投了の手でのコメントは送信しないことになっているので(将棋所の実装上の問題なのか、floodgateのサーバー側のCSA書き出しの実装上の問題なのかは私はわかりませんが)、投了局面が本当に敗勢で投了しているかはCSAファイルからは判断がつかないのです。

se-kise-ki 2013/10/27 12:45 二週間で形にした手腕は流石ですが、特急料金を払って締切日に印刷所に原稿持ち込む同人作家の様相を呈していますね・・・

yaneuraoyaneurao 2013/10/27 18:47 ↑印刷所どころか、コミケの当日に1冊売れるごとにコンビニに走ってコピー機とホッチギスで製本している感じではないでしょうか。

dara2gorondara2goron 2014/03/10 18:46 もうお探しで無いかも知れませんし、phpMyAdminのようなWindowsソフトという要求と一致するかわかりませんが、私はpupsqliteを使っています。超便利です。
https://www.eonet.ne.jp/~pup/software.html

yaneuraoyaneurao 2014/03/10 19:09 ↑私もそのソフトも使ってみたのですが、BLOB型の編集をさせようとしたら落ちるんですよね…。

dara2gorondara2goron 2014/03/10 21:46 BLOB型では使ってなかったので気付かなかったです。作者のPupさんは熱心にバグフィックスされているので、報告を送ると修正して貰えるかも知れません。役立たずで申し訳無い。

トラックバック - http://d.hatena.ne.jp/yaneurao/20131013
 | 

1900 | 01 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2013 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2014 | 01 | 02 | 03 | 04 | 06 | 08 | 10 | 11 | 12 |
2015 | 01 | 02 |


Microsoft MVP
Microsoft MVP Visual C# 2006.07-2011.06