余り時間がないので詳細は後にするとして、周辺配列と対角線について評価を行い、その評価値によって次手を並び替えして検索する方法を試みた。 方法としては以下の通り 残り14, 15, 16手のランダムな配置を作成する そのときの配置を記録 完全読みを行い、…

他の「まともな」オセロプログラムより終盤解析が遅い理由は，次の階層の最善手を探す並び替えがお粗末だからだ． とりあえず４辺と対角線の配置に付いてはパターン化し，有利なものを選択するようにすることは最低限しておこうと思う． ８つの石の配置は3^8…

現在の探索では次の階層の配置の評価を行うときと，新しく配置可能な位置を求めるときとで同じ処理を二回している． これは無駄なのでここを改善すれば速度が上がるだろうと期待していた． しかしやってみると全く反対の結果になった． なぜこのようになるか…

細かい機能の最適化をあきらめて、探索アルゴリズムを実装してhttp://www.radagast.se/othello/ffotest.html FFO endgame test suiteにある終盤解析を実際にやってみた。 最前手は正解を出力したが、そこまでの時間は以下の通りだった。 手の順位付けを最低…

このプログラムのアルゴリズムには標準的な手法のみを使用しているのだが、一つの配置を128bitの値一つで示すことで白番と黒番を64bitシフトで簡単に入れ替える事ができる。 そのためMaxノードとMinノードで関数を分ける必要はない。 ゲームが終了したかどう…

昨日条件分岐が問題ではないかと言ったが、実際は条件分岐を削ると特定の（軽い）パターンを繰り返すために速くなったように見えただけだった。 そして考えてみれば、5Mnpsというのは1ノードあたり640クロックの消費ということになる。 着手可能位置の検出が…

一生懸命最適化したつもりでまたベンチマークをとってみたが，やはり非常に遅い． 4-5Mnps程度の速度しかでない． この原因として思い当たるのが，探索関数の再帰呼び出しだ． 関数を再帰的に呼び出すと，そのとき使用していた変数をメモリに待避させなけれ…

以前SPUで乱数を使うためにメルセンヌツイスターを実装した． この時はただコードを書いただけで全く効率化していないものだったので，少し調べてみたらMMXを使用したSFMTというものがあるそうで，速いらしいとソースコードをダウンロードしてみた． しかし…

以前やったN-Queen問題では，コードのコンパクトさを期待してCで全て書いていた． しかし，現在は全てC++で書くようにしている． なぜかというと，単純に表記が自由だということもあるが，128-bit代入で警告を出さないことと，参照を用いた関数をインライン…