step2

以下のプログラムをVS2010等でビルドして実行します。
やっていることは描画毎に左右の視点を指定しているだけです。
glut32.libとglew32.libをリンクしてください。

//**************************************************************
// OpenGLでアクティブ方式の3D立体視 by g.koutaki
// ただ、wglSwapIntervalEXT(1) で垂直同期オン にして
// 偶数奇数フレームで視点位置を変えて描画しているだけです。
//
// ・モニターの設定で120Hzにして(アクティブ形式の3Dモニタ・プロジェクタはできるかと)、
//  実行時はそのモニター以外は切りました。
// ・左右の判定はしていないので、左右逆になる可能性があります。
// ・処理落ちすると左右の画像が入れ替わる可能性があります。
//
// 参考URL: http://www21.atwiki.jp/opengl/pages/80.html
//**************************************************************


#include <stdlib.h>
#include <string>
#include <GL/glew.h>
#include <GL/wglew.h>
#include <GL/glut.h>

#define WIDTH  1280
#define HEIGHT 720


//回転用
float anglex = 0.0f;
//ライトの位置
GLfloat lightpos[] = { 200.0, 150.0, -500.0, 1.0 };
//描画フレーム数
int count = 0;


char buf[255],buf2[255];
/* 描画のコールバック関数 */
void display(void)
{
	static GLfloat diffuse[3] = {1.0f, 0.0f, 0.0f};
	static GLfloat ambient[3] = {0.25f, 0.25f, 0.25f};
	static GLfloat specular[3] = {1.0f, 1.0f, 1.0f};
	static GLfloat shininess[1] = {32.0f};

	anglex+=0.2f;
	glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
	glViewport(0, 0, WIDTH, HEIGHT);
	glMatrixMode(GL_PROJECTION);
	glLoadIdentity();
	//視野角,アスペクト比(ウィンドウの幅/高さ),描画する範囲(最も近い距離,最も遠い距離)
	gluPerspective(30.0, (double)WIDTH / (double)HEIGHT, 1.0, 1000.0);
	glMatrixMode(GL_MODELVIEW);
	glLoadIdentity();
	//***********************************************
	// 視点の設定
	// フレームの奇数/偶数で視点位置を変える
	//***********************************************
	gluLookAt(
		30 * (count++ % 2) - 15,
		10.0,-200.0, //カメラの座標
		0.0,0.0,0.0, // 注視点の座標
		0.0,1.0,0.0); // 画面の上方向を指すベクトル
	//ライトの設定
	glLightfv(GL_LIGHT0, GL_POSITION, lightpos);
	//マテリアルの設定
	glMaterialfv(GL_FRONT, GL_DIFFUSE, diffuse);
	glMaterialfv(GL_FRONT, GL_AMBIENT, ambient);
	glMaterialfv(GL_FRONT, GL_SPECULAR, specular);
	glMaterialfv(GL_FRONT, GL_SHININESS, shininess);
	//回転
	glRotatef(anglex,0.8f,0.5f,0.3f);//X軸を回転
	// Teapot描画
	glutSolidTeapot(30.0);

	glutSwapBuffers();

}
void idle(void)
{
	glutPostRedisplay();
}


void Init(){
	glClearColor(0.3f, 0.3f, 0.3f, 1.0f);
	glEnable(GL_DEPTH_TEST);
	glEnable(GL_LIGHTING);
	glEnable(GL_LIGHT0);

	//***********************************************
	wglSwapIntervalEXT(1);//垂直同期オン 
	//***********************************************
}

int main(int argc, char *argv[])
{
	glutInit(&argc, argv);
	glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
	glutInitWindowSize(WIDTH, HEIGHT);
	glutCreateWindow(argv[0]);
	glewInit();
	glutDisplayFunc(display);
	Init();
	glutIdleFunc(idle);
	glutMainLoop();

	return 0;
}

お手軽3D立体視

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

こちらの環境は以下です。
DLPの3Dプロジェクタ(Panasonic PT-CW230)
DLP Link対応の3Dメガネ(Sain SONIC)

電王トーナメント

残念ならがら3勝5敗で予選落ちでした。
1敗はルートでの詰みのハッシュを見つけるとPVを更新していなかったというバグでした。
なぜfloodgateで長く流して気付かなかったというと、floodgateの場合、
相手のソフトの多くが自分が詰んでいると認識すると早めに投了していたからです。
あと、こちらでPGOビルドしたバージョンが本番マシンではなぜか動かなかったり、
並列スレッドが立ち上がらなかったりしたので通常ビルド・並列化(といってもルートだけ)を切りました。
こういう詰めの甘さも実力のうちなので、来年度頑張ります。

上位ソフトと試合していて思ったのが、とにかく読みが深いことです。
序盤で25以上イタレーション回っていました。
とにかくチェスの探索を真似して枝刈り・reductionしまくれ、という感じでした。
NPSも350万以上出ていました。
読みが深いと評価関数がある程度荒くても安定しそうです。
上記2点が目標です。

しばらくは休んで、ぼちぼち評価関数因子の解析を行いたいと思います。

btest、ktest

floodgateにbtestとktestというやつを流してます。
中身はクマ将棋なんですが、
btestはbona6.0のfv.binを初期値に現役棋士同士の対局を学習させたもので、
ktestは特徴(玉周りの金銀枚数など)を追加してゼロから学習したバージョンです。
btestはバグもあったけど、たぶんR2600いかないくらいだと思います。
クマ将棋はビットボードも使っていなくて(25万NPSくらいで遅い)、3手詰も入れていないですが
探索にバグがなくて(重要)、評価関数が優れていると、
これぐらいのレーティングは出るよ、という参考になると思います・・・。

fv.binを初期値にすると、若干の読筋は変わるけど、ほとんどbona6.0と同じになりました。
これじゃつまらないのでゼロから学習してます。ktestがこのバージョンでR2200くらい。
学習局面に似た局面だと強いのか、たまに中堅どころに一発入ったりするようですが、
序盤で失敗すると評価値も変(相手が1000点くらいなのに、自分は0点くらい)で
ボロボロで弱いです。
3駒関係は次元数が大きすぎるので、学習局面と似た局面が出てくると強いけど、
それ以外が出てくると駄目なのかもしれません。
(終盤で差がついてくると、ktestもbtestもどちらも直線で読筋も似たような感じになるようです)
玉が上がってもダメですね。確か、ボナンザは入玉形も4万局入れてたような。
いまは2万局なので、もっと沢山の棋譜を使った方がいいのかもしれない。
相対の2駒とかだと、少ない棋譜でも、割とどんな局面でも強いかもしれない。
とにかく、時間もないので学習の更新ステップ数を512とかにしてます。

王手状態のノード割合

通常探索での、王手状態のノード数÷それ以外のノード数 を調べてみました。

序盤は10%以下で、終盤で70%以上になるようです。
既出かもしれませんが、進行度に使えるかな?

ボナンザでもチェックしたけど、同じように終盤は
ほとんどが王手状態のノードですね。

王手延長の影響もあるかも。

上記から分かるように、終盤はほとんどが王手状態の探索になるようです。
王手延長もあって、反復深化のイタレーションも随分少なくなる。

したがって、王手回避手の生成速度とオーダリングが重要になると
思いますが、王手回避手のオーダリングはボナンザは
基本的にハッシュ1手とSEEぐらいです。
キラーもヒストリーも使っていない。もうちょっと精度上がらないかな。
王手回避を誤ると一気に評価値が傾くからオーダリングも難しいのでしょうけど。

ちなみに、ボナンザはハッシュ手の生成と全手の生成を同時に
やっているようですが、ハッシュ手で試してダメだったら
他の手の生成にしたほうが良さそうな気もします。