« July 2004 | Main | September 2004 »

August 30, 2004

Thell 3.0 preview

いつまでもずるずると引き伸ばしていても区切りがつかないので、一気にThell 3.0をリリースしてしまうことにした。

とはいっても、変更が大きく、ライセンスも今回からGPLを採用したりしてちょっと不安なので、日記演習履修者向けということで試しに公開してみることにした。多分この日記を読んでいる人がいちばんバグを突っつくのがうまい気がする(笑)

バイナリ
ソースコード

バグ、クラッシュ、ファイルが足りない、記述がおかしい、等々突っ込み歓迎。

ちなみにRVS版は、SkeltonについてきたRvs.cとかを含んでGPLとして配布できるのかとかいろいろ柏木さんに問い合わせ中のため、バイナリ/ソースともにとりあえず保留。

追記)
RDKに含まれるファイルは制限なしで改変・再配布可能との返事をいただいた。しかし、「Rvs.cは柏木氏の著作物だからGPLは適用されません」なんてことはできるのか?Rvs.hとRvs.cは「処理系(BearRev)に付随するコード」であるから、わざわざ俺が配布しなくてもよい気もするが。
ん、そもそもBearRevのプラグインという時点でこの問題が生じる?……あ、これは著作者である俺が「BearRevへの動的組み込みを許可する」と宣言すれば問題ないのか。

| | Comments (3) | TrackBack (1)

1Mnps(今日のFFO)

ついに出た!1M nodes/sec.
FFO#40 +38 internal:21.3M leaf:6.97M 27.954s 1012.64knps
桁あふれするのでnpsをknpsに変更した。

何をしたかというと、move/undo情報の格納にDinkumwareのvectorを使うのをやめて自前で書き直しただけ。2倍速である。move/undoの速度向上なので中盤にも影響は及び、これまで111秒かかっていた10手読みのセルフ対局が62秒で終わるようになった。すごい。

| | Comments (2) | TrackBack (0)

vector::clear()

vector::clearは各要素のデストラクタだけ呼んでメモリ領域は縮小しない、と一般には考えられているし、Effective STLなどの書籍のいたるところにその記述が見られる。vectorが保持するメモリ領域を縮小したい場合の措置として、swapを用いた技法などトリッキーな技まで紹介される始末だ。

ところが、今朝方プロファイルをとってみて、vector::clearしか呼んでいないはずの場所がやたら時間を食っていることに気づいた。そこでVisual C++ 7.1のvectorのソースを覗いてみると……なんと、clear()でメモリを完全に解放している。unnoの提唱した「ローカルにvectorを置かないでメンバ変数にしてclearだけしてごまかす」という手法でほとんど速くならなかったのはこのせいか。unnoはSTLportを使っているので、標準的なvectorの実装を使っているのではないかと推定。

DinkumwareのSTLは実装の点でSTLの常識と大分食い違っているような気がする。もちろんそれには実装者の思想があるのだろうけど。

さて、どうしよう。俺もSTLportを使うか、というところだが、配布の点から考えるとちょっと面倒だ。また、「自前超高速固定長vector」を書くかな。boost::arrayも思い浮かんだが、こいつは本当の固定長で、「現在の要素数」というカウンタを変更できないので却下。

しかしながらiteratorとか全部用意するのは面倒なので、boost::arrayをラップするクラスを作ればいいのかな?

| | Comments (0) | TrackBack (0)

今日のFFO

久しぶりの記録更新。

まず、1つ前に書いたとおりmove orderingを改善してノード数を大幅に減らした。この時点でだいたい84秒くらい。

それから手数のパラメータをちょっと調整して80秒くらいに。

ノード数の目処が立ったので次は探索速度ということで、徹底してメモリアロケーションを抑制するように修正。俺は差分方式のボードを採用しているので、自前の固定長スタックを書いて速度向上をはかった。

その結果、
FFO#40 +38 internal:21.3M leaf:6.9M 70.047s 404120nps

significant improvementではあるが、残念ながらunnoには及んでいない。向こうはbitboardの本領発揮とばかりにnpsをぐんぐん上げてるのでどうしたものか。
ちなみに今回から世の趨勢にあわせ、move orderingによる1手のmoveはノード数にカウントしないようにした。事前探索でのノード数はカウントしている。

他の記録。
TN-18 +34 internal:946k leaf:285k 3.719s 331161nps
TN-20 +22 internal:19.8M leaf:6.0M 70.703s 365270nps
OV-18 0 internal:1.0M leaf:336k 3.61s 384098nps
OV-20 0 internal:2.9M leaf:1.0M 10.938s 361126nps

TN-18はオセロ大会当日、Thell-Neothecの試合で終盤18手読み切りに1分以上かかってタイムオーバーしたという屈辱的局面である。TN-20はその2手前。
OV-18はOxelon-vsOthaの引き分けになった試合の18石空き地点。OV-20は同20石空き。大きな石差の時に有効な枝刈り手法が小さな石差の場合には逆効果となることがあるため、引き分け局面も入れてテストしている。

なにげにFFO#40よりもTN-20の方が重いテストになりつつある。昔はTN-20の方が速かったので、FFO#40に最適化しすぎたか。

追記:
おすすめされたので俺も最終1手展開。テーブルからいくつ返せるかを求められるので、実際のボードには一切さわることなく最終結果を求められる。
FFO #40 +38 21340144 6967263 58.89s 480683nps
すばらしい。この調子で最終3手展開とかするとvsOthaになるんだろうか。

| | Comments (0) | TrackBack (0)

August 29, 2004

SIGNIFICANT IMPROVEMENT

何をしてもだめだった。辺ごとに着手可能箇所を数え上げたmobilityの近似値も、開放度も、両者の線形和も、大きな違いはなく、FFO #40において中間ノード35M、葉ノード12M程度が限界であった。

そこで、そもそもの「速さ優先探索」の定義に立ち戻って実装し直してみることにした。すなわち近似値でなく、「本当の着手可能手数」でソートするのである。

すると……SIGNIFICANT IMPROVEMENT!中間ノード22M、葉ノード7.3Mにまで落とすことができた。vsOthaとほぼ同じである。unnoのアレはまあ最大瞬間風速ということで放っておくとして、まあなんとか許容範囲か。FFO #40以外のテストケースについても全てでsignificantな向上。実行時間が半分になったケースもあった。

実行時間についてもsignificantな向上が見られるが、試行錯誤の過程でコードがひどいことになっており、置換表に存在するはずのない地点でもハッシュ値を計算して検索をしてしまっていたりするので、npsをチューニングした後きちんと測定して公開することにしよう。ちなみにまだunnoの記録には全然追いついてないとだけ言っておこう。

| | Comments (1) | TrackBack (0)

O'Camlオセロ

H氏がO'Camlオセロを始めたらしい。先を越されたか。

さて俺はどうしよう。O'Camlという新しい土台の上でリベンジを挑む、というのも1つの選択だ。(もちろんそれでも評価関数やらMPCやら、向こうの方が資産が多いけど) 課題にオセロを選べば今後正々堂々とオセロ研究を続けられるというメリット(?)もある。

しかしながらO'Camlオセロをこれまで躊躇ってきたのは、「単位が来る」以外の「O'Camlで書くメリット」が見つからなかったからだ。O'Camlが最も適しているのは、コンパイラのような木構造をごにょごにょするコードであって、配列に対してひたすら演算するだけのオセロプログラミングはやっぱりC/C++の専売特許のような気がする。あと、自分が何をしたいのかいまいちよくわかってない。C++で書いた思考エンジンの忠実な移植版を作りたいのか。GUIを作りたいのか。単なる移植をして楽しいのか、意味があるのか。そもそも自分にO'Camlで書く技能があるのか。間に合うのか。

ぐだぐだ悩むよりも書いた方が速いのだろう、きっと。それにしても1日でボードと探索ルーチンを書き上げるとは…さすがだなH氏。しかも複数の実装を用意してプロファイル取るところまでやるとは…速いのはvsOthaだけではない、と。

冷静に考えれば、最初にThellを書いたとき、思考ルーチン+GUIの実装は1週間で片づけたのだった。それを考えればなんとかならないこともない?

| | Comments (0) | TrackBack (0)

な・ぜ・だ・!

unno方式をぱくり、開放度でソートすればsignificantな枝刈りができるはず、と信じてCVSから昔のコードをチェックアウトし、開放度を計算するコードをぺぺっとコピペ。Fastest-First用評価関数クラスFFEvalを修正。

さて……

悪化しとる

ノード数が1.5~2倍程度になる感じだ。なぜだ…なぜなんだ……。もはやここまで来ると、どっかにバグがあるんじゃないかと疑いたくなる。何らかの根本的勘違いによりそもそもmove orderingが正しくできていないのではないだろうか。

なんだかとっても、離散数学の問題とかOSの課題とかがやりたくなったよ。

| | Comments (0) | TrackBack (0)

評価関数再考

ここのところ探索速度向上に熱中していたが、おーくらに刺激されて再び評価関数についても考えてみる。

俺は棋譜訂正派である。棋譜中の誤りを訂正するだけで相当な精度向上が得られるはずだ。

そもそも俺もH氏も終盤完全読み切りによる棋譜訂正に注力したが、序盤~中盤については何もいじっていない。Zebraで解析をかけてみると、中盤で平気で10石も20石も損している棋譜がかなりある。だからこそ棋譜のバリエーションが増えるわけだが、最終石差予想という面では大きく読み誤る要因となるのも事実だ。

我々の評価関数は既に10手程度読めばそう大きくは間違わない(多くても4石程度?)レベルにはなっているので、中盤のある地点からセルフ対局をして最終結果を求めれば、少なくともIOSの棋譜の結果よりは信頼度の高い最終石差が求まるはずだ。

もう一つ気になっているのが棋譜中に現れないパターンの取り扱い。オセロ大会当日までにはそこをケアする余裕はなくて0のまま放置しているのだが、そういう局面も探索木の中には確実に現れるはずで、「とんでもなく悪すぎるので評価値が定まらなくて0になる局面」を「ちょっとだけ悪いので評価値が小さな負の値になる局面」よりもよい、と判定してしまう恐れはある。しかしながら、どんなに悪い局面でも全44パターンのうちどれかには見たことのある局面があるだろうという気もするが…。

kozoOthelloは聞くところによると数万程度の棋譜しか用いていないようだが、かなり強い。なんでも、学習開始前の重みの初期値としてある程度のオセロの基本戦術から算出される値を設定したそうだ。その辺が強さの1要因かも?

大会前に書きかけていた「ニューラルネットワークを用いてパターンの評価値を学習させ、出現しなかったパターンの値を予想させる」というアプローチも実験してみたいところではある。問題は、セルフ対局はちょっとファイルを準備してただ走らせればいいのに対して、コードをあれこれ書かないといけないのは大幅に時間を使うと言うことだ。課題をいろいろやらないといけない現在、ちょっと難しい……。

Ocaml最終課題にするのはどうだろう。「O'Camlによる、ニューラルネットワークを用いたオセロ局面の評価値生成器」……うーん、これって「実用アプリケーション」か?俺にとっては激しく実用的なアプリケーションではあるが…。

| | Comments (0) | TrackBack (0)

August 28, 2004

Longhorn延期

Longhornが延期になったそうだ。PC系メディアが扱うのは当然として、各種新聞等でも報じられているのがすごい。PCヲタでなくてもLonghornの行方には興味があるのか?

もともとLonghornが出るのは2007年くらいじゃないの、くらいに思っていたので特に驚かないが、WinFSはLonghornリリース後に別途リリースか。もともとはWindows NT 3.1が出るくらいの頃に言われていたCairoに載るはずの技術だったと思われるので、もう10年以上先延ばしされている技術ということになる。

いつも思うことだが、Longhornは目標が大きすぎるのではないだろうか。WindowsNT 4.0→Windows 2000も割と大きな変更だったが、それで3年半。今度はその何倍も何十倍もの変更を1バージョンで一気にやろうというのだから、そう簡単ではないはずだ。

| | Comments (0) | TrackBack (0)

離散数学演習

宿敵unnoがついにx86アセンブリやらMMXやらの禁断のドーピングに手を出していて焦るが、俺の宿敵はunnoだけじゃないのでたちが悪い。

ということで、今日は宿敵離散数学演習。多分単位来る程度は出してるんじゃないかと思うが、ちょっと微妙なのと、線形計画法に入って以降のプリントはICPCだとかMPI課題とかでまったく見てすらいないので、試験も近いことだしやっておこう。締め切りは離散数学の試験の日にしてくれるのが一番効率いいのに…と思いつつもまあ一応締め切りと言うことだからやるか。

解いてみると、思ったよりも解ける。教科書写してるという話もあるが、証明とか自分で思いつけると感激するな。俺ってこんなに頭よかったのか!?とか。最近ようやく同値類とか商集合というものの概念が理解できた俺は腹を切って(ry

グラフに関する問題は解けるところは多分解き終わったから、明日1日かけてマトロイドと線形計画法か。マトロイドは某Lilf.*のおかげで授業に出てすらいないのでまず何者であるのか理解するところから始めないといかん。プリント眺めた限りでは手を動かして概念を掴む系の問題っぽいのでなんとかなるのではないかと期待してみる。

| | Comments (0) | TrackBack (0)

August 27, 2004

枝刈り率向上せず

ここのところFFOの記録更新が滞っている。オプションによっては112sとか出るもののunnoにぶっちぎられてからというものsignificantでない記録向上はいちいち書く気もせず。

現在の戦略は深めの事前探索で置換表を用意→本格的探索においては事前探索の置換表を参考にmove orderingしながら進み、2手以上深読みすることによるmove orderingはしない、というもの。あれこれ試すも、ノード数が結局昔の戦略に比べてほとんど減らない。中間ノード31M、葉ノード12Mくらい。ほぼ同じ戦略を採ってるはずのvsOthaよりもはるかに多い。どこで枝を切り損なっているのだろうか。以前の戦略(各ノードで3~6段程度のshallow searchをしてmove orderingしながら進む、事前探索の置換表は使わない)と大して変わらないのであれば、メモリ使用量が少ないぶん以前の戦略の方がマシということになる。あああ。move/undo速度のポテンシャルはunnoのbitboardに勝てそうにはないので、少なくとも枝刈り性能は同レベルにしておかないと勝ち目はないぞ。

我々の評価関数においては事前探索で得られた評価値は完全読み切りしたときの評価値にきわめて近いはずだから、もしかしてMTD(f)使うと劇的枝刈りが!?とか期待しつつやってみるも、普通のalpha-beta(正確にはPVSだが)に比べて何ら有意な変化なし。OTL

unnoが「significant」と述べていた「双方の着手可能数に着目した速さ優先探索」であるが、俺の場合明らかに通常の速さ優先探索よりも枝が増えることが確認された。俺は正確な着手可能手数でなく、近似値を使っていることが原因だろうか?あと、ある程度のところまでは着手可能手数よりも中盤評価関数の値でソートした方が枝が少なくなる。

move ordering等で一時的に作るvectorをメンバ変数にしてメモリ領域を再利用し続けるという戦略は多分俺の場合でも有効で、npsを押し上げてくれるだろう。しかしながら、とりあえずは枝刈り性能を向上させたい。

オセロプログラミングに行き詰まっている間は現実逃避して課題をやりたくなるので、それはそれでよいことではあるのだが……。

| | Comments (2) | TrackBack (0)

システム増強

@niftyココログは便利で手軽で、俺自身が元から@nifty会員だったから選んだのだが、ユーザー数が多いからか、夜などは非常に重かった。(Movable Typeを採用しているので、記事を読むだけなら単なるHTMLの閲覧になるので全然重くないところはすばらしいけれども)

今日(正確には昨日)、システム増強が行われたと言うことなので早速テスト。うーん、言われてみれば軽くなったかな?しかし、もう2時だし、最盛期と思われる夜11時とか12時とかに見てみないと真価はわからないか。

| | Comments (0) | TrackBack (0)

August 24, 2004

今日のFFO

日本のメダルラッシュにあわせ記録更新の日々が続いている。今日の記録:
+38 internal:34826663 leaf:16888819 116.735s 443016nps

まず、アロケータをstd::allocatorに戻してみたところ記録が向上して132.297s。あれれ?

それから空所表を導入してみた。空所表は何がうれしいかというとif (board[x][y] != EMPTY)のチェックが減らせるだけなのだが、1ノードの探索で無駄なチェックが数十個にのぼるので削減する意味はあるだろうと判断。結果、116.735s。ついに2分を切るところまで来た。

今日の空所表の実装は単純な実装で、探索開始前に空所表をセットアップしたらそれ以降はずっとその表に対して着手可能かどうかチェックするというもの。途中のmove/undoによる表の書き換えは面倒なので省いた。それでも、20石空きから探索を開始する場合、それ以降の探索では20カ所分だけ着手可能かどうかチェックすればよく、これまでは常に64カ所チェックしていたことを考えると比較演算が1/3で済むことになる。

途中の探索であるが、やはりiterative deepningが一番効率がいいかなとも思う。今はmove orderingの成功率を上げたい場合は深く読んでその評価値でソートしているのだが、明らかに同じ局面を行ったり来たりしていてもったいない。ということで、置換表を2枚用意して、前回の探索で使った置換表でmove orderingをする、というのをそのうち実装してみよう。H氏の発表内容そのものだが。でもって、「これ以上はmove orderingが効果なし」というところまで来たら後は一直線に最後まで読めばよい。

ちなみに、最新のvsOtha 13.06でもって俺のマシンでFFO #40を読ませてみると、8秒……。

なーんだ、あと15倍高速にすればいいんだね、ははは……

| | Comments (0) | TrackBack (0)

毎日メダル

夜適当な時間にテレビをつけると何かしらのメダルシーンか表彰式をやっている。今夜はレスリング吉田の金メダル→表彰、チャンネルを変えたらハンマー投げ室伏の表彰式、その後体操平行棒の表彰式をLIVEで見てしまった。

「君が代は暗すぎてスポーツの場に相応しくない」と思っていたけど、表彰のシーンとかでかかると感激するな。

ところで体操といえば大暴れ中のウルジカ選手であるが、どうみてもスーパーマリオにしか見えないのは俺だけ?

| | Comments (0) | TrackBack (0)

August 23, 2004

今日のFFO

今日の記録:134.9s。ここのところ1日20秒ペースでタイムが縮んでいる。このままいけば来週にはZebra並に!?←あほ

そもそも俺の新ボード実装は「いちいち数えたり調べたりするよりもメモリ上のテーブルを参照した方が速いはず」という古典的発想に基づいているわけだが、その考えは今日では必ずしも真とは言えない場合がある。CPUに比べてメモリが圧倒的に遅いためだ。メモリ上のテーブルを使ってパフォーマンスを上げるためには、テーブルがキャッシュに入っていることが重要である。

ということで、今日はキャッシュヒット率向上を考慮した。着手可能情報を格納したテーブルの中身にこれまで「最も速かろう」という理由でintを使ってきたが、どうせ0~7の値しか取らないのだから無駄もいいところだ。ということでcharに変更したところ、136.5秒をマーク。思っていたよりもsignificantである。

ちなみに評価関数テーブルについて同様のことが成り立つはず、と考えて現在intを使っている重み係数をshortにしてみたが、特に変化なし。shortに収めるために有効数字を削減した影響か、探索ノード数がわずかに増加。10手読みセルフ対局では指し手に変化は見られなかったものの、ちょっと微妙な気分である。ノード数増加のオーバーヘッドをキャッシュヒット率向上で補っているのではないかと推測されるが、significantな向上はなかったので評価関数精度を優先して元に戻す。

ついでにもう一つ、vectorのソースを眺めていて気づいたのだが、size()の実装が_MyFirstがNULLかどうか判定した後に_MyLast-_MyLastを返すというものになっていたので、これを排除すべくカウンタとvector::size()でまわしていたループをイテレータに変更。134.9秒。ちなみにgccのSTL実装はこうなってはいかなったので、Dinkumware特有の実装かと思われる。

キャッシュサイズとか、STL実装とかにこだわった最適化をするのは末期症状な気もするが、「x86/VC++で最高のパフォーマンスを、残りのプラットフォームでは正しく動作すればよい」というポリシーなのでまあよしとしよう。

H氏の言うとおり、地道な努力を1つ1つして速くしていくしか道はないのかもしれない。

メモ:コードを何も変えてないし、背後で何も動いてないはずなのに以前より記録が悪いときには、一旦コマンドプロンプトを閉じて新しく開いてから計測すると速い。なんだそりゃ?

| | Comments (3) | TrackBack (0)

公開に向けて

ThellもThellRVSも、主要機能は完成していつでも公開できそうだ。ThellRVSは設定ダイアログと、レジストリの読み書きも実装したからかなり便利になった。

しかしなぜ公開していないかというと、メッセージ機能もつけたいだとかThellのデザインを変えたいだとかそんな理由。version 3.0からはGPL2で公開しようかと思うので、一応全ソースコードにGPL的文句を書いた。

検討事項。
・ThellRVSにはRVSのスケルトンのコードが入っているがそれも含めてGPLとしてよいのか。←作者に聞くのが早いという話も。
・学習プログラムなんかのツールも含めて公開するのか(なんか、希望された)。

もっとも公開できない最大の理由は、毎日のごとくパラメータが変わってちょっとずつ速くなるのでちっとも落ち着かないということだったりする。

| | Comments (0) | TrackBack (0)

August 22, 2004

今日のFFO

残り19石空きとか18石空きとかで、1手読みだけのmove orderingに頼るのはどうも怖い。ということで根に近い方ではもう少し深く読んでmove orderingをかけるようにした。171.7秒。322knps。

終盤と中盤はやはりまったく別物だ。中盤で遅くならないよう、中盤探索速度も測定しながら終盤を調整。

追記) 置換表にまだまだ余裕があったのでもう一段入れてみる。166.1秒。315knps。

もういっちょ) PVSを実装してみる。158秒。ほんのちょっと速くなった。中盤も1割弱速くなった。ついでに、他のテストデータとして、タイムオーバーで敗れたThell-Neothecの棋譜の20石空き及び18石空きも使うことにした。この18石空きの読み切りに1分半近くかかって敗れたのだった。今デスクトップでやると15秒。

ちなみにFFO #40の最新のデータ:
+38 internal:34198463 leaf:17899162 158.359s

| | Comments (0) | TrackBack (0)

今日のFFO(#40)

日記のごとく、FFO endgame test suiteの結果を載せていくことにしよう。今日の記録は202.5秒。前回は253秒。

今日は枝刈り性能でなく、ノード探索性能の向上に主眼を置いた。やったことは、
・vectorのコピーを抑制
moveの際に、これまで変更点を記録したvectorを作成→スタックに積むとしていたが、これだとvectorをコピーしないといけないので、無駄である。ということで、スタックに新しいvector要素を作成→その要素の参照を得てそこに変更点を記録、とした。これで228秒。ちなみにここでいうスタックはヒープ/スタックのスタックではなくて、データ構造のスタックのこと。

・pool_allocator
vectorのアロケータとしてboost::pool_allocatorを指定した。試験的なコードによるテストではこの変更で2割程度速くなると踏んでいたが、実際にはほとんど差が出なかった。225秒。

・movable_iterator
現在のノード探索では、まず全着手可能位置を探し出してvectorに突っ込んで返すということをする。ここが重い処理であるのは周知の事実だ。move orderingをかける場合には全着手候補がわからないといけないので、このアルゴリズムは動かしがたい。しかしながら、探索木の葉に近い方ではmove orderingを行わないため、違ったアプローチが可能であるはずだ。そこで作ったのがmovable_iterator。これは++演算子によって「次の着手可能位置」を指すイテレータである。もし途中でbeta cutが起きた場合、全着手可能位置を列挙するのに比べて処理が軽い。また、vectorを使わないためアロケーションの負荷もかからない。これで202.5秒。
将来的に空所表を採用する場合、イテレータの実装を書き換えるだけでよいはずだ。

今日が終わった時点で最高速度は324knps。1Mnpsは出したいが……。「差分方式の方が速いに違いない」と信じてやってきたが、実際のところどうなんだろう。もっともSTLに頼りすぎという話はある。最近はほとんどメモリアロケーション速度との闘いなので、動的メモリを使わない設計にできれば劇的な速度向上もありうる!?

しかし、このテストは相当難しい局面なのではないかと思う。そもそも20カ所空きの時点で10カ所も着手できる。さらに、多分どの手もそれほど大きな差がない(=枝刈りしにくい)のではないだろうか。探索の進み具合を見ていてそう思う。このテストで好成績を上げることができれば、たいていの局面では一瞬で読み切れる気がする。

| | Comments (0) | TrackBack (0)

August 20, 2004

EOS 20D発表

「お盆明けにはD2Xが出る」とか2chで噂されていたが、ふたを開けてみれば出したのはC社の方だった。

何気なくPC Watchを見て知ったのだが、C社からEOS 20Dが発表された。APS-Cサイズ820万画素、秒間5コマ、JPEGで連続23コマ(RAWは6コマ)。シャッターも電子シャッターなしで1/8000s、起動時間0.2sec。EOS 10Dの欠点はあらかた払拭されているように見える。というか、俺がD200に期待していたスペックそのものである。これが実売19万か。驚異だ。

ついでに、これまでKissDigital付属レンズを除いてAPS-C専用レンズを出してこなかったC社からついにAPS-C専用レンズが発表された。これでAPS-Cサイズのカメラでも超広角撮影が楽しめるようになる。とはいっても、EF-SだからEOS 10Dには対応しないのだろう、多分。しかもLレンズではない。残念。

さてこれで我らがニコンも出さないわけにはいかなくなった。いつまでもD70の成功だけで食っていけるわけはないので、とっととハイエンドのD2Xを出し、そしてD2XとD70の間を埋める存在、EOS 20D対抗としてのD200を出さなければならない。KissDigital対抗として出たD70がKissDigitalはおろかその上のD100クラスをも置き換えるほどの性能だった事を考えれば、20D対抗として出るD200が20Dを余裕で圧倒してくれることも期待できる。例えアテネの映像に並ぶレンズが全て白レンズだろうと、俺はニコンを信じて待ってるぜ。D200が出たら即買う、と先行宣言しておこう。

そういや先日FujifilmからS3Proが正式発表されていたが、カメラボディはニコン、撮像素子は富士、っていう組み合わせのカメラは出ないものだろうか。フィルム一眼レフを考えればそういう組み合わせはあって当然であり、何も撮像素子まで完全自社供給にこだわる必要はないと思うのだが(というか現在Nikonのデジタル一眼レフはD2Hを除いてSONY製CCDらしい)。デジタル一眼レフの黎明期にはそういうことも行われていたようだが、普及期に入った今、再び両者が手を組むことはないのだろうか。

| | Comments (0) | TrackBack (1)

またもや回帰分析

話を聞いていると、どうもThellの評価関数精度はOxelonのそれに一段劣るような気がする。先読み手数ではThellの方が上回っているはずだから(現在はどうなっているのだろう)、Oxelonと同等以上の評価関数を搭載できればより強くなれるはずだ。

Oxelonとの違いは何かということで考えてみると、使っている棋譜、parity、corner3x3パターンがある。

とりあえず簡単にできるものとして、Logistello棋譜12万個を除いたIOS30万のみで学習させてみた。こっちは棋譜訂正してるのでOxelonに比べて精度は上なはず。しかし、結果に大した違いはなかった。Logistello棋譜ありの場合とほとんど変わらない。

すると、やはり「triangleパターンよりはcorner3x3パターンの方がよい」説だろうか。triangleパターンはTurtleというプログラムで採用されているということで採用したのだが、Turtleって「鬼のように強い」という話は聞いたことないし…不安になってきたZO。corner2x5パターンを導入した今、triangleよりはcorner3x3の方が重複が少なく(そもそもtriangleはcorner2x5によって完全に包含される)、corner3x3の方が石数が1つ少ない分1つ1つのパターンの出現頻度が上がって精度がよくなるのでは…とか。何よりも、Buro先生はcorner3x3パターンを使っていらっしゃるではないか。Buro先生の言いつけに背くと天罰が下ることは先日の大会でも如実に示された通りである。

とはいっても使用パターンの変更はそれなりに気力を要するので、課題の目処が立つまではちとやる気にならず。というか課題がまったく進まない。このままでは単(ry

| | Comments (1) | TrackBack (0)

August 19, 2004

今月のCマガ

お金を積みに銀行まででかけたら、足が攣りそうになった。やばい。このところ家も出ないし、本当に指先の筋肉しか使ってないからな…。

帰りに本屋に寄ったら、C MAGAZINE 2004年9月号が売ってたので買ってきた。特集は「思考するコンピュータ」と「Generics」でもう俺がウハウハしてしまうタイトルが目白押しだ。

「思考するコンピュータ」の方は、広く浅く思考ゲームのアルゴリズムについて解説しているという感じ。alpha-betaとかは今更、って感じだが、学習法のところが興味深い。オセロの場合はまあ棋譜もあるし、普通に回帰分析してやりゃいいんじゃないの、という感じだが、一応オセロにTD学習法を適用しようと言う試みもいくつか存在するようだ。概念くらいは理解しておいて損はないだろう。

| | Comments (0) | TrackBack (0)

美浜原発

美浜原発の事故は、タービンに送る高圧蒸気が漏れたという話だから、原子力発電所に限らず火力発電所でも同じ問題があると思うのだが、なぜ「他の原発も点検」という話しか出てこないんだ?単に原子力という言葉に皆敏感だから?

と思ったら火力発電所も調査へっていう記事があった。それにしてもやっぱり、みんな原子力発電所が絡むと大げさに騒ぎすぎると思う。

もっとも、点検を見落として事故を起こすような会社に原子力発電所の運用をまかせてよいのか、という不安はあるな。

| | Comments (2) | TrackBack (0)

August 18, 2004

性懲りもなくチューニング

今更ながらFFO endgame testが気になって試してみた。

とりあえず簡単そうな#40から……940秒!?

さすがにありえないのでいくつか思い当たる点を変更。400秒。コードをよく読むとなんと置換表の検索と追加だけして評価値を見てなかった。ありえん。270秒。

その後、いくつかいじったが結局260秒、内部ノード46473614、葉ノード21286269が限界。Zebraは2.3秒、vsOthaの大分昔のデータで13秒程度……。もはやなんかマシン性能の差とかどうでもよくなるくらいの差だ。

しかも葉の数は21Mだから多分vsOthaのデータと同じオーダー。枝刈りについてはまあ妥当なところに来たということだろうか。となると後は純粋なノード探索性能ということになる。

世間的には終盤に来るとnpsはぐんぐん上がって数Mnpsくらいいくらしい。vsOthaも1.5Mlpsということだからnpsにしたら3M~4Mnpsくらい?俺の結果だと260knpsくらいで、中盤の探索とまるでかわらない速度しか出ていない。何がここまでの差を生むのか……_| ̄|○

追記) 試しにループ展開&history heuristicもどきしてみた箇所がコンパイルされてなかったのでやりなおしたら253秒。期待したほどのsignificantな成果は出ず。あれれ?

| | Comments (0) | TrackBack (0)

August 17, 2004

はじめてのWTL

thellrvs_config.png

現実逃避してRVS版Thellの設定ダイアログなどを書き始めてしまった。Windows用フレームワークとしては、WTL(Windows Template Library)を使うことにした。かねてから使いたいと熱望していたライブラリだ。

WTLは名前が聞かれなくなって久しいATL(Active Template Library)のWindowsプログラミング用フレームワークで、MFCが完全に継承モデルをベースとしたクラス設計をとっているのに対し、C++のtemplateを前面に押し出した構造となっている。(そもそもMFCが最初に登場した当時はtemplateという仕様がC++になかったのではないか) WTLはタブブラウザDonutに使われたことで有名になった。

MFCと比較した場合、WTLは単なるテンプレートライブラリのラッパにすぎないので、非常に軽量である。ライブラリをリンクする必要もなく、単にインクルードファイルをぺぺっと貼り付ければ使える。今回も、既にあるプロジェクトにWTL関連のヘッダをいくつか加えるだけでウィンドウを構築することができた。また、一部MFCと同じように使える部分もある(CString, DDX/DDVなど)ので、MFCに慣れた人にとってもうれしい。

しかしながらWTLには問題もある。それはMicrosoftの態度だ。WTLはMicrosoft内のほんの一部の開発者(噂では一人とか!?)が趣味のように作っており、ドキュメントがほとんどない。そもそも.NETが提唱されて以降、Microsoftはとにかく開発者に.NET Frameworkを使わせようと躍起になっているので、legacyなWin32プログラミングのためのWTLは常に日陰の扱いであり、ついには見放されてオープンソースプロジェクトになってしまった(*1)。またMFCのように開発環境がきっちりサポートしているわけではないので、ダイアログエディタからイベントハンドラを追加して…というわけにはいかない。自分でメッセージマップを書くしかないのだ。ドキュメントがないのだからMSDNのヘルプだってない。開発環境からF1キーを押して…とすることはできない。(一部、ATLと共通のクラス等については資料がある場合もある)

(*1)もっともオープンソースプロジェクトになったということは、今後Microsoftの機嫌でつぶされたり更新停止になったりすることがなくなったわけで、よいニュースである。

WTLに関する情報はMicrosoftからはほとんで出ていないようなので、ユーザーがまとめたサイトを利用した方が早い。日本のサイトではSo-SoftwareとかWTL研究所とか。海外ではCodeProjectなんかがよさそう。しかしこれらの人はどこから情報を得たのかな…。サンプルを読んで、あとはひたすらインクルードファイル探検だろうか。先人の努力に感謝せずにはいられない。

Microsoftが出しているドキュメントとしては、ATL3.0 ウィンドウクラス:入門がよい。ATL/WTLがどのようにウィンドウを扱うのかという基本概念について解説している。

| | Comments (0) | TrackBack (0)

August 16, 2004

Thell3に向けて

成果物は公表しないとね、ってことでThell 3.0.0を公開に持って行くべくちょっといじってみた。

とりあえず、評価関数データファイルをバイナリ化してサイズ削減&読み込み時間の短縮に成功。open modeにios::binaryをつけわすれていてしばらく悩んだ。

それから、「クリップボードを経由して棋譜をコピペ」を実装。これがあると非常に便利だと言うことに今回気づいたからだ。じっくりにらんで、棋譜保存に関するバグも取れた。

それ以外の大幅拡張はちょっとやってる暇ないので、あとはドキュメント整備して公開、って感じかな。

| | Comments (0) | TrackBack (0)

August 15, 2004

オセロ大会終了

去る8月13日、オセロ大会が開催された。俺はThellの新思考エンジン"spot"で挑んだ。

結果から書くと、3勝3敗で2位であった。優勝はH氏のvsOthaで5勝1分。やはりスタートラインが違うvsOthaとの勝負は分が悪かったか…。しかし、一般リーグ4人の中で最も評価関数の実装が遅れていて一時は絶望感も漂っていた俺だが、よくここまで健闘できたと思う。勝因は高速な評価と、Buro先生のお言葉に従って作られた安定した評価関数か。

簡単に結果を書いておくと、
Thell3(黒) 対 vsOtha 13.06(白) 30 - 34
vsOtha 13.06(黒) 対 Thell3(白) 34 - 30
Thell3(黒) 対 Neothec3(白) 12 - 51 (時間切れ)
Neothec3(黒) 対 Thell3(白) 23 - 41
Thell3(黒) 対 Oxelon(白) 34 - 30
Oxelon(黒) 対 Thell3(白) 30 - 34

今回の大会で最も悔やまれることはタイムマネジメントをこれ以上ないほど軽んじていたこと。結果、タイムオーバーで1試合落とし(タイムオーバーがなければ4勝2敗だった)、もう1試合も制限時間ぎりぎりの4分58秒使い切るというきわどさで辛うじて勝利したので、タイムマネジメント機能の軽視が悔やまれる。とはいえ、タイムマネジメントに手が伸びなかったのはひとえに俺の実装力のなさとそのための余裕のなさのせいであるので、大いに反省すべきところだ。

大会には参加者以外にも先輩方や生物情報実験組もギャラリーとして現れて、なかなかの盛り上がりだった。また、H氏の友人のP氏(オセロ6段保持者)も駆けつけてくれて、特別ゲストで我々のプログラムと対局して下さった。結果、プログラムの完勝。とりあえず6段以上の実力にはなったということか。旧Thellが1級程度と評されていたのでこれはsignificant improvementと言ってよいだろう。

以下、簡単にオセロ大会までの俺の動向などをまとめてみる。結構日記では秘密主義を貫いてきたために重要な事は書いていなかったりするのだ。

Continue reading "オセロ大会終了"

| | Comments (2) | TrackBack (0)

August 13, 2004

決戦前夜

他の参加者がみなそれぞれ書いているので俺も。俺はというとプレゼンに追われていたりする。

12時頃できあがった新評価関数はかなりよいできだが、これまで勝っていた勝負に負けることもある。逆に、勝つときにはこれまでよりも大きく石差を広げることができている。どちらの評価関数を使って勝負するか非常に迷うところだ。O氏も言っているように「確実に勝てる」ということはないだろうから、ここは勝負をねらって例え負けを作っても残りの試合で石を大きく取るという具合で勝負に出るか。もっとも明日の参加者に対しても同じような傾向が得られるとは限らないわけだが…。

結局のところ、既存のアルゴリズムを理解して自分で実装して確かめるという、ただそれだけの作業になってしまった感がないでもない。もう少しいろいろ実験してみたかったのだが、やる気が出なかったり時間がなかったり…。前向き枝刈りは考える余裕がなかった。なにしろまともな評価関数ができあがったのが大会2日前という具合なのでありえん。

とはいえ、探索速度には満足している。中盤10手読み、終盤17手完全読み切りは大丈夫だろう。move orderingもかなりうまくいっているようだ。Thell2.xでは考えられない速度だ。評価関数も、最終的には全てをテーブル参照で片づけることができたので、当初思い描いていたものよりも高速になった。あまりsophisticatedな時間管理はつけられなかったが、それなりに時間を有効活用する工夫はするつもり。

評価関数は可もなく不可もなくといったところか。定石に乗るかどうかについては、多分25前後くらいまでは乗ることが多いようだ。しかしながらZebraの定石に乗ることは何を意味するのか、いまいち微妙なところである。単に棋譜によく現れるというだけなのかもしれない。

明日の勝負ももちろん楽しみだが、それ以上に俺は他の参加者のプレゼンテーションが楽しみだ。O氏の独自アルゴリズムの数々、H氏の超高速終盤解析ルーチンやニューラルネットワークを使っているらしい評価関数、U氏の神のような超高精度評価関数の秘密、などなど。大いに期待している。

さていつになったら寝られるのだろうか。

| | Comments (0) | TrackBack (0)

August 12, 2004

hash table tuning

大会前最後の調整、ということでこれまでさぼっていた置換表ハッシュテーブルの解析。表の埋まり具合、平均リスト長、リスト長の標準偏差などをとってみる。

その結果、これまで使っていたハッシュ関数はありえないほど悪いことがわかった。表が4%しか埋まってないのに平均リスト長1.3、最大リスト長4とか。ちなみに平均リスト長はそのハッシュ値が少なくとも1回使用されたものに対して(つまり、長さ1以上のものに対して)はかっている。

ちょっとハッシュ関数をいじって、使用率4%で平均リスト長を1.03、最大リスト長2くらいにまで下げることができた。表が100%埋まった際のリスト長の標準偏差も減少した。

しかしながら最大の発見は、中盤では置換表の出番はほとんどなく、終盤でも20手読みとかしない限りほとんど意味がないということである……。

| | Comments (0) | TrackBack (0)

RVS版Thell

ベアとの対戦は全てRVS(Bear Reversi用の外部思考ルーチン)を使って行っている。オセロ大会が終わったらRVS版のThellも公開したいところだが、そのためにはいろいろとやらないといけないことがあるなぁ。

・設定ダイアログ
読み手数とかを与えるダイアログくらいベア側で用意してくれればいいのに…というのは甘え過ぎか。現在は読み手数を変える際にはコンパイルしなおさないといけないのでありえない。ダイアログってどうやって作るんだっけ…。っていうかオセロ大会の参加者の誰かが作ってソースをばらまけばよいのでは。

・起動が遅い
評価関数の重み係数を読み込むところで10秒くらいかかり、その間Bear Reversiが固まる。これは本家Thellでも同じ問題が起きるので、なんとかしたいところ。現在デバッグ用にテキストファイルで数値データを置いているが、バイナリにしたらかなり小さく&速くなるんじゃないの、と期待。文字列をパースして変換する手間がいらなくなるもんね。

ところで今、探索&評価関数ルーチンはグローバルなstatic変数として、RvsInit時にnewしてRvsFinish時にdeleteしてるんだけど、これってThellRVSが2つロードされた場合(ThellRVS vs. ThellRVSの場合)にはどうなるんだ?DLLが何回ロードされようと参照するグローバルなメモリ空間は一緒なのか?

| | Comments (0) | TrackBack (0)

vs. vsOtha

vsOtha。2001年夏頃だったと思うが、「Thell」で検索して見つけたこのページに、vsOthaというソフトの名前が書いてあった。どれどれ、と思って落としてみると異様にでかい。40MB近いデータベースを持っている。生意気な。ということで対局してみたところ、我がThell(2.2くらいか?)はあっけなっく白旗を揚げたのだった。

あれから3年、なんとvsOtha作者が同じISの人間だったと知り、評価関数と探索ルーチンに磨きをかけた今、再び俺はvsOthaに戦いを挑んだのだった……。

Continue reading "vs. vsOtha"

| | Comments (0) | TrackBack (0)

August 11, 2004

俺的significant improvement

あれこれあって、ようやく実用的な評価関数ができあがった。評価関数チューニングの途中で評価速度の劇的向上(多分)というありがたい副産物も生まれた。

今日できた新しい評価関数では、とりあえずベアには負けなくなった。6手読み同士で先手の時引き分け、後手の時2石勝ち。この条件下で、だいたいの思考時間がThell: 4~6秒に対してベア: 1分くらい。Thellの読み手数を上げていくと、石差が開いていく。今のところThell(9, 16, 14) - Bear(6, 16, 14)で34石勝ちが最高か。この条件でも、使用時間は00:48 - 01:01でThellの方が短い。みんなはどういう条件でベアと試合してるのだろう。「同じ持ち時間で」という条件ならかなり読めそうだ。

Thellを作り始めて以来、常に倒したいと思ってきたベアに余裕で勝てるようになって、大喜びすべき場面なのだろうが、もはやまわりの雰囲気的に「ベアには当然30石勝ちでしょ、そろそろZebraくらい倒さないとね」という感じなので、うかうか喜んでもいられない。それにしてもベアは強いな…。ちょっと真面目に評価関数を作ればイチコロだと考えていたが、相当作り込まれているようだ。しかしながら、いかんせんその遅さがネックか。

その後は大した進展なし。評価関数のバリエーションをいくつか作ってみたものの、「どれも同じ」という結論に。なぬぅ。さらに、学習をすすめるとより弱くなるという現象も発生。学習を進めていく中で、平均誤差はほぼ一定を保って少しずつ小さくなっていくのだが、各パラメータが激しく動いているのが気になる。そもそも学習のさせ方になにか決定的問題があるのか!?あああ……。

Zebra先生に言わせると、まだまだたまに決定的なミスをしているようだ。勝利や引き分けも、ベアのミスに救われているようなところもあって、まだ安心するには早い状況だ。

さて、あと1日、何ができるだろうか。あ、ていうかプレゼン作らないと。

| | Comments (0) | TrackBack (0)

朗報

Y住さんからメールが来て、形式言語理論の単位が取得できたとのこと。うほっ、いい単位。

| | Comments (0) | TrackBack (0)

誤差が、誤差がぁぁ

いよいよ待望の学習計算開始。予想では前回作った評価関数の問題点を全て克服してsignificant improvementが得られるはずである。

序盤~中盤のステージに関しては明らかに改善が進んでいるのが見て取れる。大幅に誤差が減少。しかしながら…終盤付近の誤差が大きすぎる。前回の計算よりもはるかに大きい。むーなんだこれは。

前回の半分の回数しかIterationしてないということもあるので、単に収束速度の違いであればよいのだが…。

| | Comments (0) | TrackBack (0)

August 10, 2004

計算計算

いよいよオセロ大会までの日数も数えるところあとわずかで、せっぱ詰まってマシンをぶんまわしまくり。自分のデスクトップ(Pen4/2.4C)、学科ノート(PenM/1.3)、時間帯によって居間のデスクトップ(Celeron/2.0)を同時稼働。

しかし、学科ノートは思った以上に性能が悪い。Pen4と同等くらいの性能は出してくれるものと期待していたのに、半分か1/3の性能しか出ていない。なぜ?メモリはDDRじゃないのだろうか。というかオセロ大会はこのマシンで行われるので、真剣に実機での性能評価をするべきかも。

オセロは条件分岐が多く整数演算ばかりだからPen3系コアが圧倒的有利、とこれまで信じていたが、実はそんなことはない?条件分岐は分岐予測の範囲内でよくあたり、巨大なテーブルを参照してのオペレーションを多用するのでFSB帯域が圧倒的に広いPen4の圧倒的有利、なのかも。

そしてCeleronマシンは思った通り遅い。遅いだけならまだしも、なぜか高負荷をかけると不安定に。俺のプログラムが突如クラッシュしたり、エクスプローラ等の他のアプリケーションも次々クラッシュして正常にシャットダウンをかけることすらできなくなったりした。メモリあたりが壊れているのだろうか?

前途多難だ……。というか、計算終わるのか?

| | Comments (1) | TrackBack (0)

August 09, 2004

shockin'!!

学科ノートを取りに行って、せっかくだからクラスタにジョブを投入して、家に帰ってメールを見たら……「cscクラスタ構成マシンの停止について」なにぃぃ!!

そういえば4年生が地下室で「クラスタ…停止…」とか話しているのが聞こえた気がするが、節電対策の一環としてクラスタの一部を落とすという話だと思ったし、まさかサービス停止前にアナウンスくらいはあるだろうと思っていたのだが…やられた。まあ「ついでに」程度の小さめのジョブだったから、実行できなかったからといって致命的な被害はないが…。

アナウンスなしでいきなり落としても問題ないほどまったく利用されてないということか?ありうるな…(苦笑)

入れ替えと言うことは、もっと高性能なマシンが入るのかな?とちょっと期待。

| | Comments (1) | TrackBack (0)

TECRA M1タッチパッド暴走の件

7号館地下室に学科ノートを取りに来た。このところ家でHHKとThinkpadのキーボードばかり触っていたのでこのキーボードの感触はどうもいかん。ありえん。

ところで、Vine Linux 3.0 betaを入れてからというもの、本体のトラックポイントやタッチパッドをさわるとマウスポインタが暴走してあちこちを勝手にクリックしたような状態になってしまう現象に悩まされていたのだが、やっと解決策を講じる事ができた。[vine-users:066811]の通りであるが、/etc/X11/xorg.confのSection "InputDevice"中の

Option "Protocol" "IMPS/2"
Option "Protocol" "GlidePointPS/2"
に書き換えてやればよい。なお、俺の環境は[vine-users:066811]の方と同じく、Section "InputDevice"のマウス関係のセクションが"Mouse0"(/dev/psaux)と"Mouse9"(/dev/input/mice)の2つ存在していたが、Mouse0の方を書き換えた所うまくいった。想像だが、Mouse0が内蔵タッチパッド、Mouse9がUSB外付けマウスの設定かな?

そういえば、Vine Linux 3.0も正式リリースされたので、家のThinkpadも折を見てバージョンアップしなきゃ。

ところでbetaのままのこの学科ノートは現在どうなっちゃってるんだろう?apt-getはしたが、もしかしてVineSeedになってしまっているのか?

| | Comments (1) | TrackBack (0)

Smithfield?

いつもながら、後藤さんってすごいよなーということで後藤弘茂のWeekly海外ニュースなど読んでいた。

Prescottの実効速度が出ない、消費電力はばかでかいというのにうんざりして、次期デスクトップはMeromとか、モバイル系コアのCPUにしたいと思っているのだが、当面出なさそうだなぁ。2005年夏に院試が終わった後、院試お疲れ記念ということで新デスクトップ購入、と行こうかなと思ったのだが、2005年夏時点では大して魅力的なマシンがなさそうだ。しかも、ケチな俺が1年後に買えるものというとだいたいその1年前、つまり今頃出た商品ということになるので、Prescottじゃん。却下。

ま、普段は全然性能を必要としないんだけどね。オセロ大会までの間でいいから1000倍くらい高速なマシンを数台欲しい。

| | Comments (0) | TrackBack (0)

特に進展せず

オセロの方に特に進展はなし。

評価関数を改善する手法として2つ考えていて、1つはコンピュータが頑張る方法。もう1つは俺が頑張る(コードを書く)方法。前者は数日前からやってるが一向に終わらず。後者は前に書いたコードをぺぺっと貼り付けたら終わってしまった。俺もクラスタを使うべきなのか?そうなのか?とりあえずクラスタを使えば学習は合計1時間程度で終わらせられそうなので、何かの場合の手段としていつでも使えるように準備はしておこう。

そろそろ大会当日を見据えたスケジュールを立てて学習とか始めないと。学習は多分1晩あれば余裕だが、その結果が悪かったらどうしよう……あああああ。その場合にはもはや打つ手なしなので心配してもしょうがないか。ということで気楽に行こう。きっと次の計算ではsignificant improvementが得られるに違いない。ふふふ。

なんとなく暇だったので各パターンの出現頻度を分析してみた。予想以上の激しい偏りがある。うーむ。

| | Comments (0) | TrackBack (0)

August 07, 2004

第2外国語の価値

俺は中国語選択だった。よく「最近はドイツ語なんて使うことはない。ビジネスなどを考えると中国語や韓国語の方がこれから役立つ」とか言われるが、中国語が読みたい!あるいは読めてよかった!というような場面って今のところおめにかかってないなぁ。父親宛の中国語spamを読んで何を売りたいのかわかったくらいか。

むしろドイツ語(Buroの論文)とかフランス語(Nikon新製品のリーク情報サイト)の方が読みたいと思う。まあこの辺は単語の雰囲気が英語と似ている場合もあるので、字面を追っていくとそれなりにわかったりもするが……。

もうまったく既知の言語・文字とかけ離れたものを学ぶのもおもしろいな。3学期には韓国朝鮮語をとってみた。(結局不可ったが) ハングル文字を一応読めるようになったはずであるが…忘れてしまったな。アラビア語なんかもやってみればよかったかも。あのミミズのような字を読めたり書けたりしたら感動モノだ。ミミズといえばタイ語もすごいっぽい。タイ語は字の形成が非常に複雑なのでコンピュータ上で表しにくいとかいう話を聞いたことがあるな。

| | Comments (0) | TrackBack (0)

August 06, 2004

あわわわわ

unno日記を見るたびにうちひしがれるぞ。「ある方法」ってなんだ!?そして、は、速い……。そして評価関数の精度は圧倒的にOxelonが勝っているっぽい。序盤15手定石進行って……。むむむ…。

まぁ,なんですか。結局のところ大事なのは深読みよりも。評価関数。深読みは,実は本質じゃない。優秀な評価関数があれば,深読みなど不要。
大筋で同意。優秀な評価関数がある結果としてより深い読みができる→ますます強くなる、という構図か。

俺はといえば、今日は何も進展なし。数日後のsignificant improvementを祈りつつ、ひたすら計算。「数日後」が大会開催の前であることもついでに祈りつつ……。

ここ数週間、ひたすら数字と文字列と向き合うコーディングばかりしてきたので、計算させつつ気分転換にGUIへの組み込みでもやってみるかね。と思ったところで問題発生。思考ルーチンは別のプロジェクトとしてCVSに登録してしまっているのだが、どうしよう。思考モジュール単独での更新はやめにして、Thellのディレクトリに組み込んでそっちで管理するのがよいのか。しかしBearプラグインの話もあるしなぁ。双方からうまい形で思考ルーチンを共有したいが……ライブラリ?

AIからUIへのイベント通知は、かつてはAIにtemplate methodを用意してそれをオーバーライドし、通信を実装していたが、今回はObserverパターンで行こう。

ついでにバイナリファイルの扱いも研究。テキストファイルに数値データを格納しておくのは可読性(デバッグ時)と可搬性に優れるとはいえ、領域、読み取りともに重すぎる。istream::readとかostream::writeとか使えばよさげ?あとは、チェックサムなんかもつけたいね。重みデータベースが破損していて「Thellは弱い」なんて言われてはたまらん。

こんなふうにどうでもいいアイディアはいくらでも思いつくんだけどなぁ。はぁ。

| | Comments (2) | TrackBack (0)

OCamlオセロ

俺はもちろんC++だけど、OCamlで頑張るというY氏には非常に期待している。

なぜかというと、俺はICFPに出てない→OCaml最終課題どうしましょ。8月を半月まるまるオセロにあててしまうし→これだけ頑張ってるんだからオセロの研究成果をうまく生かせないものか。

ということで、Y氏からノウハウを得ようと手ぐすね引いて待ってますので、ぜひぜひ頑張って下さいませ。

| | Comments (3) | TrackBack (0)

August 05, 2004

評価関数ができた

この場合の「できた」というのは、探索ルーチンに組み込んで実行できるようになったことを意味する。これまで回帰分析計算は一応終わっていて、評価関数クラスMidEvaluatorも作っていたのだが、肝心の計算結果を実行時の評価関数に適した形に変換するコードができてなかったので、実行ができなかった。

まだGUIに組み込むところまでは作っていないが、とりあえずコマンドラインで実行してThell 2.3.3(中)と対戦。一応、先読み手数は合わせておく。Thell 2.3.3には36石勝ち。調子に乗ってベアともやってみるも……こちらが後手で2石負け(33-31)、こちらが先手で引き分けだった。双方共に(mid, WLD, perfect) = (6, 15, 15)で行った。ベアとは探索速度が桁違いなのでこっちは7手とか8手とかいってもいい気がするが、まあそこは評価関数の試験ということで。もっと精度を上げないとだめだな。

ところで9手読みをやらせてみるとやたら遅い。置換表つきαβの中盤9手、終盤15手完全読み切りで自己対戦させると240秒ほどかかる。ただし評価関数用データを入れ替えると90秒くらいになることもあるので、要は評価関数の精度がよくないためmove orderingを大分間違っているということらしい。

全ては評価関数の精度向上にかかっているということだ。なんとなくだが、Oxelonに並ぶことはできたか?

| | Comments (1) | TrackBack (0)

マイブーム

ここ数年、俺のコーディングスタイルはほぼ一貫していて、毎日スタイルが切り替わっていた高校生の頃がウソのようである。なんとなく自分のプログラミングスタイルの固定化は成熟を意味するような気がして、「ああ、俺もようやくプログラマとして一人前なのかな」などと勝手に考えていたが、ここに来て再びスタイルを変えたい欲求がむらむらと。

ここ数年、俺の命名規則はJava風形式(メソッド名の先頭単語のみ小文字、後続の単語は単語先頭を大文字)に多少C++が加わったものであった。C++風とは、sizeを返すメソッドに対してgetSize()という名前をつけるのではなく、size()という名前を与えるということである。

ところがここのところ、C++、特にSTLばっかりながめていたせいか、get_max_lengthのような完全C++風命名形式がすっきりしていていいような気がしてきてしまった。どうしよう。

ちなみにさらに昔はMicrosoft風命名規則(先頭文字も大文字、例: GetSize())を使っていたので、徐々に小文字化しているということだろうか。

| | Comments (0) | TrackBack (0)

August 04, 2004

熱との闘い

今日は一日中計算させていた。そこで、働き通しのマシンを労うため、少し熱問題について考えることにした。俺のデスクトップの最大の問題はケース内温度が異様に高いことである。設置場所が風通し悪い場所であるとか、音にこだわりすぎてケースファンを弱いものにしてしまったとか、フラットケーブルが空気の流れを止めているとかいろいろな要因が合わさっているとは思うのだが、要因の1つとして電源装置のファンの弱さがあるような気がしてきた。Seasonicの静音電源をわざわざ9000円もはたいて買ったのだが、どうもケース後部に手をあててみるに、ケースファンからの風量に比べて明らかに電源ファンの風量が小さい。電源部がかなりの熱をもっているにもかかわらず、である。

ということで、こんなことをしてみた。

DSC_4209.jpg

ケース上部の電源部にあたる位置に、ノートパソコン用の冷却マットを敷いて、その上にいらなくなったヒートシンク類を載せる。なんかバカみたいだが、ヒートシンクが相当暖かくなっているところをみると、一定の放熱効果はあると思うのだがどうだろう?

| | Comments (0) | TrackBack (0)

夜明け

ここのところ、GMT+3くらいのタイムゾーンで生活しているので、ここ日本においては毎日夜明けを見ることができる。そんなわけで、撮り貯めた夜明けの写真の中から何枚か。

DSC_4192.jpg

DSC_4202.jpg

DSC_4204.jpg

今回の撮影でわかったこと。VR 70-200mmは実はフレアに弱い。70-200mmで撮った太陽は見られたものじゃなかった。上の太陽はED 70-300mmによる撮影。完璧なレンズなんてないってことか…。

ところで、この撮影もある意味望遠鏡で太陽を見る行為に等しいと思うのだが、大丈夫なのだろうか。

| | Comments (1) | TrackBack (0)

chicken

あれは何年前の出来事だろうか、別れるように人から言われたことがあった。結局は別れることになるのだと。けれども俺は、そのあまりのつらさを想像するだけですくみあがってしまい、未だに決心がついていないのだ。

Continue reading "chicken"

| | Comments (0) | TrackBack (0)

August 03, 2004

探索を修正

「藤田は、ループを書き直した。」
「計算速度が、1000倍になった。」
「歓声が、あがった。」

で、スタジオに招かれたゲストが涙をぬぐって、「ヘッドライト・テールライト」が流れてめでたしめでたし。

なんて簡単には行かないんだよ世の中。

それにしてもオセロのプログラミングってどうしてこんなに実装するモノが多いんだろう。ハッシュ表とか、ソートとか、アルゴリズムの基本中の基本は当然のこととして、数値計算の最適化アルゴリズムとか統計だとか巨大なデータをいかに効率よく扱うかとか、考えることが非常に多い。そしてバグが本当に見つけにくく、見つけたバグの原因特定がこれまた難しい。バグの結果がクラッシュといった目に見える形で現れてくるのではなく、ごくたまに指し手を間違うといった微妙な現象として現れてくるので本当にいやらしい。普段ISでやらされてる課題よりはるかに難しいし大規模だ。

で、せっかく置換表を実装したのだから効果のほどを確かめてやろうと、8手読みをさせてみたところなんと置換表の有無で指し手が違う。なにぃぃ!

結論としては、alphabetaの1カ所の比較条件をちょっと変えることで修正。6手では現れなかったバグが8手読みで出現したということか。

ということでバグ修正記念にベンチマーク。中盤8手+終盤16手完全読み切り、中盤評価関数は単純テーブル、move orderingなし。

time(sec)中間ノード葉ノード
置換表なし1691620924314617864
置換表あり63.063378268845179

move orderingがなかったりして実際の使用環境にどれだけ近いのかという疑問も多少あるが、やはり置換表の使用は探索速度にsignificant improvementをもたらすとしてよいのではないだろうか。

| | Comments (0) | TrackBack (0)

衝撃の新事実

今朝寝床でEffective STLを読んでいたらすごいことに気づいた。

「たとえば、sizeof(int) == 4であるプラットフォームで、int型の値を格納できるメモリが必要な場合、operator newには4を渡すが、allocator<int>::allocateには1を渡す。」(Effective STL 第10項 P.50)
ということはだ、置換表でメモリを確保する際に何十倍ものメモリを確保してしまってるということだ。

道理で異常なほどメモリ消費量がでかいわけだ……。

| | Comments (0) | TrackBack (0)

少し光が

一昨日書いた学習プログラムに無駄が多いような気がして眺めてみて、ちょっと書き換えたところ劇的に高速化した。どのくらい高速化したかというと、30分かかっていたループが1.6秒くらいになった。

速すぎて、見えな~いという感じであるが、従来と同じ方法で算出している誤差は着実によくなっているし、多分問題ないのだろう。とりあえず少数のサンプルをかけてみたところ、iteration300回じゃちょっと足りない気もする。まあ多分300回時点でそれなりによい値にはなっているっぽいので、それ以降は時間が許す限りぶんまわす、というところかなぁ。

ちょっと中間ファイルを覗いてみたら、parityが負の係数を示しているのが気になった。unnoも同じようなことを言っていたような。これはもともとこういうもんなのか、あるいは他の説明変数との多重共線性か。計算させてる間に統計の教科書を読み直してみるか。

(追記)わかりやすい変数の組み合わせに対して相関係数を計算してみたけど、「ほっとんど相関ナシ」という結果だった。ということは、「1.このステージにおいてはparityは負に働く(マジ?)」もしくは「2.俺がparityと称する値を計算するときに符号を間違えた」のどっちかだな。

| | Comments (0) | TrackBack (0)

August 02, 2004

置換表

机の上に論文とかプリントとかが散乱していて地層状態…。いつになったら片づける時間が取れるんだろう。

結局評価関数はたいして進展せず。一日中実験するもどれも途中で罠に気づいて行き止まりに、の繰り返し。はぁ。実験の副産物として置換表ができあがった。昨夜(今朝)はおぞましいバグによって呪われていたが、1晩寝て再び見たらみるみるバグがみつかってバグ退治。やっぱりマシンとにらめっこしていてもしょうがないな。寝るのは大事だ。

置換表は多分仕様を満たす動作をするようになったので、あとはハッシュ関数と各種細かなパフォーマンス上の調整だろうか。実はchain長の統計をまだとってないので、実はものすごく偏った表になってるかもしれない。

| | Comments (0) | TrackBack (0)

Thell << (超えられない壁) << Oxelon, Neothec, vsOtha

な気がしてきたぞ最近。あああなんで俺だけ評価関数できてないんだ。

というか、回帰分析の計算が遅すぎる。1ステージ分の約24万件のデータを1回まわすのにPen4 2.4GHzでちょうど30分かかる。しかもbetaをでかくしてぶっ飛ぶのが怖いから超小さな値にしていて、1回のループでたいして向上しないし。これだと、1ステージあたり、Buroが述べているところの300回分ループするのにすら150時間かかるぞ。Buroは「Pentium Pro/200MHzで20時間で全部終わった」といってるので、明らかに何かおかしい……。しかしあのbeta=1はなんなんだろう。絶対間違いだと思うのだが…。

とりあえず、orz

| | Comments (0) | TrackBack (0)

August 01, 2004

Cyprum購入

夏バテの原因は家に引きこもって一日中お茶ばかり飲んでいることだと判断し、ヒキコモリの俺らしくもなくアキバへとでかけることにした。(出かける先がアキバという時点で何か間違ってると思う人はこんなblog読まない方が身のためでである)

ということでかねてから買いたいと思っていたCPUファン、Cyprumを購入。確かパソコン工房で3600円弱だったと思う。Socket478用のCPUファンとしては高めの部類だ。

休日のアキバは人が多すぎていやだと思っていたが、今日は夏の暑さのせいかそれほど人も多くなく、また休日は大通りが歩行者天国になっているので意外と歩きやすい。しかしアキバという街はどうしてコスプレしたお姉さんが普通に歩いていらっしゃるんでしょう。コスプレ喫茶の店員さんというわけでもないと思うんだよなぁ、アレ。

家に帰って装着、の前に、今ついているPentium4リテールのCPUファンの取り外しに苦労した。ツメががっちり食い込んでいてはぎ取るのがなかなか難しい。

装着して起動した後、負荷をかけるテストをしてみたところ、確かに性能がいい。CPU表面温度は52度に落ち着いた。これはHyperThreadingによる両方のCPUをフルに使った場合、片方だけをフルに使った場合どちらも同じ結果となった。リテールのファンだと57度くらいまでいっていたので5度も下がっている。また、リテールファンではファン回転数が3,600rpmなのに対してCyprumは2,700rpm。つまりCyprumはより低いファン回転数でより高い放熱効果を上げているわけで、3600円の価値はあるといえるだろう。

気になる音であるが、リテールのファンでみられたような耳障りな高音は聞こえないので、無音というわけではないが相当マシになったといえる。(もしかすると今聞こえているファンの音はCPUファン以外の電源、ケースファンといった部分の音かもしれない)

気になるのはここにあるレビュー結果よりも温度が高くなっていることだ。俺の環境だとケース内温度(SYSTEM)が44度とかなってるので、ケースファンをもっと増強すべきなのだろうか?

DSC_4198.jpg
久々に開けたケース。ほとんどのデバイスをオンボードで済ませているため拡張バスが寂しい。

ところで、HyperThreading(HT)ってやっぱりすごいと思う。いくら最近の高速CPUであっても、CPU使用率を100%にするとそれなりにウィンドウの描画とかが重くなるものだが、HTがある場合は1スレッドがCPU100%で暴走していても全然気にすることなく使うことができる。2つ目のスレッドが暴走し出すと重くなるのはしょうがないけど。Intelはよく「HTがあればバックグラウンドでウイルススキャンしながらでも快適に操作できます」とか言っているが、あながちウソではないな。

| | Comments (4) | TrackBack (0)

« July 2004 | Main | September 2004 »