数学とコンピュータの悩ましい（？）関係
http://wired.jp/2013/04/09/computers-and-math/
定理が成り立つかどうかをコンピュータに判定させる事の是非が論じられているらしいですが、これって詰将棋の世界でも過去に似たケースがあったんでしょうかね。
私の感覚では「作った詰将棋が完全作かどうか」って判定はコンピュータ任せで良い様な気がしますが、これも詰将棋ルーチンの発展前（df-pnが出る前位？）では話が違ってくるでしょうし。
話は戻って数学の方。
単純に「定理が成り立つかの証明」を目的とするなら、その為の手段としてコンピュータを使うのは効率面で良い事でしょう。ただ、「定理の証明の過程で、汎用的に役立つ手法*1を構築する」事を目的とするなら、それはコンピュータには荷が重い気がします。
この辺は一言で「数学」と言っても色々分野があるらしいんで、部外者がどうこう言っても無意味でしょうか。
ただ、人工知能の研究をしていた一人としては、人間の知的活動の一部をコンピュータに肩代わりさせるのは人工知能の進歩の証ですし、そういう面では数学にコンピュータを利用するのは「アリ」なんじゃないかと思います。
パラメータを更新したのを投入
今日の22:00の回からです。
学習はプロ棋士等の棋譜約6万局からボナンザメソッドで学習したもので、1ステップ目の途中（1万5千棋譜処理後）のものです。
ローカルではLesserkai相手に20連勝しましたので、前のよりは強くなっているはずです。
んで、ボナンザメソッドが1ステップ終了したら、それをベースに自己対戦の強化学習（PGLeaf）で更に学習させる予定。
…選手権、間に合うかなぁ。
ちなみに現在の2週間レーティングは1419。最低でも後150上乗せしてgps500には追い付きたい所です。
あくまで私の予想ですが、gps500と同等で選手権2次予選進出争いに参加出来るか出来ないかのギリギリって感じだと思うので。
評価関数と学習ルーチンのどうでもいい話
http://d.hatena.ne.jp/Gasyou/20120508/1336489213
昨年の選手権直後ですが、C++のテンプレートを使って評価関数の評価・学習ルーチンを実装する方法を書きました。
で、あの後色々やっていて、やっぱりこれは設計ミスだったんじゃないかと思えて来ました。
まず、例の書き方だとevaluate()関数・forEach()関数・EvaluateProcessorクラス・LearnProcessorクラスの4つがありました。
ただ、これはあくまでTDLeaf(λ)を実装する為の最低限必要な関数・クラス群です。
んで、方策勾配法を実装しようとすると新しい関数・クラスが必要になってきますし、パラメータクラスに新しいメンバ変数・メンバ関数が必要になってきます。ボナンザメソッドを実装すると更に関数・クラスが増えます。
そうすると何が大変って、評価関数を書き換えた際にほぼ同じ関数・クラスを実装し直す必要があります。
という訳で、今度書き換える時は評価関数自体にはevaluate()・forEach()・EvaluateProcessorといった、評価関数に最低限必要なものだけを実装し、その他の関数・Processorクラスは学習ルーチンの方に持たせようかと検討中。ついでに、forEach()はpublic関数にする必要があります。
こうすれば、forEach()関数に互換性さえあれば、異なる評価関数クラス間で学習ルーチン固有の関数・Processorクラスを共有可能です。
また、パラメータクラスもテンプレート引数として与えてやれば、複数の学習ルーチンで使う各種変数・関数がゴチャゴチャする事も無くなるはずです。
ついでに、評価関数自体はシンプルになりますし、少なくとも現状の7000行近いファイルになる事は無くなるはずです。
今のプランでは選手権後に全面書き直しを検討中なので、やるとしたらそのタイミングでやります。
