Blunderについて

shogi


今年の第19回世界コンピュータ将棋選手権に出場したBlunderは、C#で書かれたコンピュータ将棋である。


コンピュータ将棋ではC#で書くとC++などで書かれた場合の1/4〜1/2ぐらいの速度しか出ないのだが*1、一次予選を3位で通過した。二次予選は惜しくも7位で終わったが、初出場とC#というハンデのわりには、十分な奮闘を見せたと思う。


そのBlunderのソースがこの度、公開された。
http://hp.vector.co.jp/authors/VA039571/blunder/


いまのところソースが公開されている将棋プログラムを強さ順に並べると、


GPS将棋
Bonanza
Blunder
うさぴょん
…(以下略)


こんな感じか。


GPS将棋とBonanzaが圧倒的なのは言うまでもないが、Blunderも、C++で書き直したりすれば、あとR200〜300ぐらいは上がる見込みがあるので、もう少し本当は評価されてもいいような気はする。


そう言えば、aki.さんは卒論も公開されているが、謝辞のところに私の名前があったり…。



Blunderの著作権は私にもあったり…。



私は来年か再来年には、自分の(Blunderとは別の)将棋ソフトで大会に出場したいと思っている。
「やねうらおの名前で出るからには、それなりの成果を残したいしなぁ…」とか考えているとなかなか出場できないんだけど。


ところで、2chにこんな書き込みがあった。

28 名前：名無し名人[sage] 投稿日：2009/05/03(日) 20:11:28 id:JEw/iLBn
ソース公開されてるソフトより弱い将棋ソフト作ってる奴はなんなの？馬鹿なの？死ぬの？

上の書き込みは、単なる煽りだとは思うが、痛いところではある。
実際、ソースを公開されているGPS将棋やBonanzaより何故弱い将棋ソフトしか作れないのかというと、


・GPS将棋のソースがC++のtemplateを駆使してあって複雑すぎて読み切れない。理解しきれない。
・Bonanzaのソースは、ビット演算のようなテクニックを多用してあって、どのビットが何の意味なのか読み解くのが至難の業。
・極力、人まねをしたくない。自分なりの方法で成果を出したい。そちらのほうが優勝することよりはるかに意味がある。(と考えている)
・Bonanzaメソッドを正しく理解できていないので学習がうまくいかない。
・Bonanzaメソッドを使いたくない。
・GPS将棋やBonanzaのソースコードは、膨大な試行錯誤の結果であって、同じような経験をしていない他人がそれらのソースコードを読んでも、どこをどういじれば棋力が改善されるのか方針すら立たない。
・すでに発表されているコンピュータ将棋関係の論文をすべて理解するに至っていない。
・理解していても、どう実装していいかわかっていない。
・プログラミング能力が欠如していて、効率的な実装ができない。


など、開発者によって多少事情は異なると思うが、それぞれいろんな事情があって、各自が複雑な心情を胸にいだいている。


あまり、触れてはいけない闇の部分なのかも知れないが、もし大会で優勝することに何らかの意義や喜びを感じるのなら、何故ソースコードを公開されているものより弱いものしか作れないのかという点をもっと真剣に考えてもいいんじゃないかと思う。


来年は情報処理学会が50周年ということで、日本将棋連盟の方で、来年の10月頃にプロ棋士との対局イベントを考えているらしい。


もし、プロ棋士に公式の場で勝ったコンピュータ将棋第一号として歴史に名を残したいのであれば、来年の選手権での優勝を狙うしかない。コンピュータ将棋開発者に残された時間は余りにも短い。


【追記 2009.5.11】


コメント欄で「改良プロセスそのものの全自動化に賭けるしかない」という意見をいただいてまして、これは、まあコンピュータ将棋の開発者ならたぶん誰もがやれればいいなぁと考えていることなんですが、何故出来ないかというと以下のような理由によります。


良いfeatureとして
1)計算しやすい評価項目であること
2)それでいて、意味があること
3)他のfeatureとうまく共存できること。
などが条件として必要であって、1)は、GPS将棋の場合、こういう(→ http://www.sgtpepper.net/kaneko/diary/20090507.html#p04 )感じなのですが、これと同等かこれ以上のものを自動的に生成するには、かなり高度な人工知能が必要になります。(自動的に整数論の定理を発見していく人工知能が昔ありましたが、あれ以上のものが必要になります。)


事前に生成パターンを決めておいて、座標だけ違う、みたいなfeatureならば自動生成できるでしょうけど、それは自動生成したと言えるかどうかは微妙。


また、生成したfeatureが本当に効果があるのかを試すには実際に対戦させてみないといけないのですが、あまりに微少なfeatureだと結果に反映しにくいので、本当に効果があるのか判断できないんですよね。


まあ、現時点で自動化が成功していないのはそんな理由によるものです。結局、将棋の棋力のある人がfeatureを考えて、それを実装するほうがいまのところ、効率的に良いものが作れるということになりそうです。

*1:C#だと配列アクセスのときに境界チェックすることや、methodのinline化が甘いことなどの理由による。