アクティブ形式の3Dプロジェクタで3D立体視のCGを出力しようとしたら DirectXや特殊なGPU(quadro)を使う必要があるようで敷居が高いと困っていたけど、 OpenGLの垂直同期とれば簡単にできると話を聞いたのでやってみたら、 すんなりできました。 さすがにこれだけだと、同期が甘いし、左右フレームの区別がつかないというものだけど とりあえずちょっと試す分にはいいと思います。 こちらの環境は以下です。 ・DLPの3Dプロジェクタ(Panasonic PT-CW230) ・DLP Link対応の3Dメガネ(Sain SONIC)

残念ならがら３勝５敗で予選落ちでした。 １敗はルートでの詰みのハッシュを見つけるとPVを更新していなかったというバグでした。 なぜfloodgateで長く流して気付かなかったというと、floodgateの場合、 相手のソフトの多くが自分が詰んでいると認識すると早めに投了していたからです。 あと、こちらでPGOビルドしたバージョンが本番マシンではなぜか動かなかったり、 並列スレッドが立ち上がらなかったりしたので通常ビルド・並列化（といってもルートだけ）を切りました。 こういう詰めの甘さも実力のうちなので、来年度頑張ります。 上位ソフトと試合していて思ったのが、とにかく読みが深いことです。 序盤で２５以上イタレーション回っていました。 とにかくチェスの探索を真似して枝刈り・reductionしまくれ、という感じでした。 NPSも３５０万以上出ていました。 読みが深いと評価関数がある程度荒くても

bonanza6.0が有利/不利とする３駒関係トップ１５０が出力できるようにしました（９九玉固定） http://navi.cs.kumamoto-u.ac.jp/~koutaki/shogi/p150/ http://navi.cs.kumamoto-u.ac.jp/~koutaki/shogi/n150/ 大駒の利きを止めるケースが点数が高いのだろうか。 現局面にこれらのパターンがあると点数が高いわけではなく、 そこから探索を進めた末端局面でこのこれらのパターンがあると 点数が高くなります。 点数が高いパターンはプロの手をルートに探索を進めていくと これらのパターンが多く残っていたということなんでしょう。 あと、いくつかバグを修正しました。コードと実行ファイルです。 http://navi.cs.kumamoto-u.ac.jp/~koutaki/shogi/fva0.1.zip 主成

入力した局面をbona6.0で探索して、求まった末端局面で どのような評価値が利いているかを解析するツールを作りました。 例） http://navi.cs.kumamoto-u.ac.jp/~koutaki/shogi/report.html 実行ファイル） http://navi.cs.kumamoto-u.ac.jp/~koutaki/shogi/fva.zip fv.binは各自で用意してください。 バグがあったので修正版とコードも上記リンクにあります。 将棋所の局面コピーでtest.csaに張り付けると便利だと思います。 解析例 上のreportは 先手：クマ、後手：sakurapyon (bona6.0の評価関数)の３０手目の解析結果です。 http://wdoor.c.u-tokyo.ac.jp/shogi/view/index.cgi?csa=http%3A%2F%2Fwd

iPad上で動画をキャプチャしてOpenCVの処理をかけるさいのメモです。 OpenCVの動画キャプチャ関数がそのまま使えないので注意が必要です。 iOS開発やxcodeがよく分かっていないので苦労しました。 コード１式(xcode用)： http://navi.cs.kumamoto-u.ac.jp/~koutaki/VideoCamera-opencv.zip 以下を参考（というかほとんど同じ）にしています： 実践! iPhoneアプリ開発 http://news.mynavi.jp/column/iphone/041/index.html 上記と差分・注意点です。 公式ページよりiOS用のopencv2.frameworkをDL Build phaseのLink Binary Librariesに追加 Build settingsでCompiler for C/C++をApple L

空いた時間にちまちま作っています。 指手を生成するコードを生成するコードをデバッグした後に、 生成された指手を生成するコードをデバッグしないといけないので大変です。 キャプチャとドロップはなんとかできたけど、王手の回避手を同じように作ると 組み合わせが膨大になりすぎた。 というのは、 王の位置（８１）×王手をかける位置（８１）×合い駒を打つ持ち駒のパターン（１２７）で、 王手を回避するパターンを生成しないといけない。 コードだけで、１Ｇバイトを超えてコンパイルが止まってしまう。 コード例は下にあります。パターンをひたすらswitchで展開していく。 前回も書いたけど、狙いは、いままで配列で駒の利きを計算していたので、その配列参照をなくすことで高速になること、 事前に利きの配列を用意する必要がなく、関数をコピペすればいきなり使える、 というものです。 なにかアホなことしていて、根本的に方針が

合議の実装が大体終了。 並列探索を行うには、局面構造を変えないといけないし、 （今のクマ将棋は探索局面とハッシュをstaticに持っている） マルチスレッド処理の方法がよく分からし、 そもそも並列探索自体がとても大変そうなので 実装が簡単そうな合議にせざるを得ない。 こんな感じに、クマ将棋を３つ立ち上げて、 マスターがそれぞれに局面データを入力すると、各クライアントが 最善手を返す。それらを集計。 プロセス間通信も良く分からなかったので、 プログラム間の通信はファイルでやり取りするというお粗末さ。 具体的には、 /1 /2 /3 というフォルダを作っておいて、マスターが 各フィルダに局面データのテキストファイルin.txtを置くと、 クライアントはそれを読み込んで、最善手をファイルte.txtで出力し、 in.txtを削除。マスターがte.txtを回収して合議。 これでなんとか動いているの

ボナンザの３駒関係（ＫＰＰ）を配列版で使う方法です。 ビットボードで使う場合はボナンザのコードをそのまま使えば良かったのですが、 れさぴょんやsimkのような盤面を配列で管理している場合は、コードがそのまま使えないので苦労します。 というのは、オリジナルのfv.binのＫＰＰのデータは単純に[王][駒1][駒2]のデータが入っておらず 対称性を利用して、データが正方形ではく三角形の並びになっているからです。 コードを全て載せると多くなるので要点だけ載せます。 なお、定数等はボナンザのコードを参考にしてください。 #define PcPcOnSq2(k,i,j) pc_on_sq2[k][i * fe_end + j] // KPPテーブルを三角テーブルから正方テーブルに変換 for(k = 0;k < 81;k++) { for(i = 0;i < fe_end;i++) { for(j

評価関数の学習を始めています。とりあえず、理解と動作確認のため ボナンザを使って学習して、どれくらい強くなるか試しています。 オリジナルのfv.binを超えるのは無理だろうけど、R2000行きたいところ。 ボナンザを使って学習する方法のメモです。 もっといい方法があると思うけど、とりあえず動いたということで。 まず、shogi.hに以下を追加。 #define TLP #define NDEBUG #define exam_bb(a) a TLPを定義すると、学習時にマルチスレッドで並列処理できるようです。 あと、NDEBUGを定義しないと、学習時にassertに引っかかったので。 exam_bbは局面に間違いがないかチェックする関数みたいだけど、コンパイルエラーがでたので 無効にした。 学習にはrecords.csaというcsa形式のデータが必要です。これを準備します。 ボナンザはプロ棋

通常探索でも静止探索でもＳＥＥが重要らしい。 ＳＥＥとは、あるマス（ターゲット）で駒を取り合ったときの最終的な駒の交換値。 同歩とか同銀とかがずっと続く状態。 ボナンザではswap.cでSEE = swap(手)で計算している。 静止探索ではSEEが正の手（駒損しない手）を追加していく。 実装での注意点は、駒を取り合っていると、飛車とか角とかの飛び利きのある駒が、 新たにターゲットに利きを持つようになるので、 駒の動かすたびに、利き情報を更新しないといけない。 うさぴょん本でもＳＥＥについて書かれている。うさぴょんでは 駒を配列で管理しているけど、ボナンザなどビットボードタイプでは どうしているのだろうと調べたが、結局良く分からなかったので ソースを読んでみた。 以下、それをまとめたものです。ご参考に。 suzumer.web.fc2.com/SEE.pdf 直接アドレスを張りつけてくださ