GA将?開発日記~王理のその先へ~

ネタ勢最強を目指して絶賛開発中。

2010-09-01から1ヶ月間の記事一覧

相変わらず発散しまくり

ちょっと思い付いて、π(s,a;θ)が小さい(選択確率が低い)手は学習対象外としたり、シグモイド関数のゲインgをいじってみたりしたんですが、相変わらず将棋だと評価値が発散します。 これって、どっか勘違いしてるか間違ってるか、そういうのが原因か?

将棋だと評価値が発散する問題

三目並べがちゃんと収束したのは、どうも発散前に引き分けに収束したのが理由っぽいです。 んで、将棋だとなかなか収束しないので、収束前に評価値が発散しちゃう、と。 んー、どうすっかなぁ。

失敗orz

評価値が発散しててダメでした。大抵の局面で評価値が1か-1になるんで、マトモに指し手選択が出来ない状況です。 学習率下げても発散を先送りする程度の効果しか無いし、さて、どうしたもんか。

明日からの予定、どうしよう?

とりあえず学習が上手く行ったケースですが、二つほど考えてます。 (1評価関数のまま)学習を並列化した上で、もっと深い探索で学習させてみる。 複数評価関数での合議にリトライ。 要するにシングルエンジンでの強さを求めるか、弱エンジンの強さはそこそ…

と言うか、上のグラフおかしくね?

TDLeaf(λ)だとだんだん勾配が緩やかになる曲線状だったんですが、上のグラフ、すごく一直線です。 これってどんどん値が大きくなって、発散しちゃうかも。やだー、明日の朝が怖いデス。

うがー、まだ収束しねー

とりあえず開発用マシンで走らせてる、5五将棋バージョンのパラメータ。 駒の価値の比率はまぁ妥当そうな感じなんですが、まだ収束した雰囲気が全く無いです。 これは、一晩走らせないと無理ぽ?

よっしゃァ!

評価値計算でシグモイドを使う様にしたら、ちゃんと駒の価値がプラスになってくれました。 これだけじゃまだ強くなってるか不明ですが、数時間学習させてからsspあたりと連続対局してみます。

評価値の計算式を変えるんで、方策勾配法の式を再計算

まず、行動価値関数(≒評価関数)の式は下記の通り。 ここで、Bは特徴量の数(次元数)、は特徴量、sはシグモイド関数(+α*1)で、下記の通り。gはゲイン。 次に、方策は下記の通り。 次に、は下記の通り計算出来る。なお、式中の// 2010/10/17 21:10修正 *…

方策勾配法で温度調整するの、やめそうかな

expの計算で簡単にオーバーフローするし、かと言って多倍長演算は面倒そうだし。 とりあえず自前のアルゴリズムで探査率見つつ温度自動調整は出来てるから、当面それでいいや。楽だし。

ソフトマックス方策を用いた方策勾配法の計算式その2〜温度も学習しよう〜

方策πの式は下記の通り(再掲)。 Qは価値関数で、sの手番が優位な局面ほど高い値となる。 んで、温度Tで偏微分すると下記の通り。 // TeXの式が長すぎて画像表示されなくなったので、続きは別に。

僕の考えた完璧な素数計算プログラム

http://d.hatena.ne.jp/mclh46/20100927/1285605192 のタイトルを見てふと思い出したので。 学生時代の友人が「10以下の素数を出力するプログラムを作成せよ」という問題に対して「これなら完璧。絶対にバグがないぜ!」って言って書いたもの。 printf( "1 2…

と金の価値は

昨日書き忘れてたんですが、三目並べで先後両方共学習するバージョン、ちゃんと収束する様になりました。 原因はソフトマックス方策の温度設定で、1.0だとNG(先手勝ちになる)で0.2だとOKでした。 んで、昨日の夜から学習用マシンで将棋の方の学習をしてい…

やっぱり間違ってた

まぁ、コード書く前に気付いたんでダメージ少ないですが。

温度パラメータの微分

計算してみたらやったら複雑になったんだけど、本当に合ってるんだろうか?なんか心配。

相変わらず、先後両方学習すると先手勝ちになります

先手だけ学習・後手だけ学習で収束速度を比較してみましたが、特に異常なし。 後手だけ学習だとちょっと収束遅いんですが、これは元々先手有利な状況で学習を開始し、一旦は引き分けにする事を学習してから後手が勝つ事を学習しているせいだと思われます。 …

HYBRID W-ZERO3販売再開

http://willcom-blog.com/archives/2010/09/00654.php このまま消えるのは惜しい端末なんで、復活してくれて嬉しいです。 基本的に以前のモノと同じですが、回線と通信部分のハードがSoftbank網対応に変更されているみたいです。 その他詳細はリンク先をご覧…

うわああああああああああぁッ!!

収益の計算式、おもいっきし間違ってたよ orz え、てか、この間違ったコードで何で収束したんだ、三目並べは? あれ、え? なんで?

今日やった事まとめ

手数オーバーでの引き分けの設定を300手から1024手に変更 引き分けの評価値を色々試す 学習中は千日手を回避する様に修正 あれ、ちょっと設定変えて走らせるのしかやってない?ひょっとして。

多少は囲うつもりがあるんだろうか

+---+---+---+---+---+---+---+---+---+ |^と| |^と|v香|v飛|v王| | | | +---+---+---+---+---+---+---+---+---+ |^と| | |v角| |^と|v桂| |^と| +---+---+---+---+---+---+---+---+---+ |^桂| |v香|v歩|v歩| |v歩| |^と| +---+---+---+---+---+---+---+---+…

手数オーバーの場合に対処

学習時は引き分けの評価値を「負けても良いから引き分けを回避する」様な値に設定したら、ある程度対処出来たみたいです。 てか、こんないい加減な対策で良いんだろうか…

あぁもう!

手数オーバーで引き分けばかりですよ orz おまけに駒の価値はマイナスになるし、どうしたら良いんだ?

論文「Evaluation-Function Based Proof-Number Search」読んだまとめ

http://d.hatena.ne.jp/issei_y/20100926/1285467964で紹介されてたの。 自分用のメモなので、ざっくり書いていきます。 アブストラクト 証明数探索(EF-PN)をベースにした評価関数を提案するよ。 評価関数ベースの証明数探索(EF−PN)を提案するよ。 1. イ…

駒の価値が軒並みマイナスになってやがる

駒価値_歩 : 14.4347 駒価値_桂 : -17.3304 駒価値_香 : -4.01357 駒価値_銀 : -7.92035 駒価値_金 : -29.7224 駒価値_角 : -16.4094 駒価値_飛 : -5.79995 駒価値_と : -32.0053 駒価値_圭 : -35.5501 駒価値_杏 : -29.4556 駒価値_全 : -33.3404 駒価値_馬…

GA将!!!!!は無敵囲いを覚えた

らしい。 140局終了 +---+---+---+---+---+---+---+---+---+ |^杏| |v銀|v王| |^龍| |v桂|v角| +---+---+---+---+---+---+---+---+---+ | |v飛|v金|v香| | | | |v香| +---+---+---+---+---+---+---+---+---+ | |v桂|v歩|v歩|v歩|v歩| | |v歩| +---+---+---+-…

基本に戻って三目並べ

先手だけ学習・後手の方策は固定とか、それの先後入れ替えた場合とかではちゃんと収束する様になりました。 ただ、先後両方共学習させると何故か引き分けに収束しないので、今度はその辺を何とかする必要がありそうです。

ようやく将棋の方も挙動が一致したんで

学習用マシンに投入してみます。 今のペースだと一日1万7千局ペースなんで、ざっと昨日までの5〜6倍程度。大分高速化出来たみたいです。

よっしゃ、デバッグ完了

数値ベクトル型の実装が2種類あるのですが、高速バージョンと低速バージョンで挙動が一致、収束もちゃんとしてくれました。まだ三目並べですが。 次は将棋で挙動一致するかテストして、それがOKなら本番稼動に投入します。

Google IMEって、文節区切りのアルゴリズムがちょっと弱い?

いや、使ってて何となく思っただけなんですが。 ちなみにバージョンはGoogleJapaneseInput-0.12.434.0。

まだまだバグ持ち

三目並べで一応学習が進む様にはなったんですが、まだ一つ二つバグが残ってる感じで、引き分け率が90%にしかなりません(汗 まぁ、将棋の学習始める前に気付いて良かったと思って、デバッグでもしますか。

高速化出来た!

と思ってたら、バグって三目並べで収束しなくなってます orz さて、デバッグしますか。