| ここ数日は、バイトのプログラムを作っていたせいで将棋の方はあまりはかどりませんでした。 さらに今日から実家に帰るために、開発環境がPentinum166MHzのマシンになります(泣)。 リビルドに何分かかるんだろう。ＴＯＷＮＳ時代のコンパイルを思い出します。 |
|
相手の時間を利用するルーチンの仮実装を完了する。あまり試したわけではないですけど効果は
無いよりましといったところでしょうか。相手の思考時間の利用など書くと先進的な感じがしま
すが、効率性は極めて悪いです。 つまり相手の思考時間５秒を利用した場合、相手が指してから５秒思考した場合の効率性には 遠く及ばないということです。相乗効果などは全く期待できません。もっとも、相手が長考す る場合は多少の効果があるのかもしれませんが… |
| バグ取りに一日かかった。しかも原因が高速化させるために変数の型をintから _int8にしてたところが限界範囲値を超えたためというしょぼい 理由でした。配列のオーバーフローのエラーは原因と関係無いところでエラーが起きるので 解明が難しいんだなぁ〜これが。 |
| やっぱりというかなんというか…。高速化ばかりに気を取られていて動作確認テストを全く しなかったためにバグ頻発ソフトになってしまいました。これじゃなかなか公開できませんね デバッグが急務です。新しい高速化のネタで実装している相手の思考時間を利用する部分も かなり危険。ばぐばぐばぐばぐば〜ぐ。 |
|
局面データ更新関数部分を高速化させるために、局面を進めるときに変化したデータを配列にとって
再利用する方法を思いつき実装しましたが、配列にアクセスする時間が予想以上に大きいらしく逆に
遅くなってしまいました…。この手のパターンは結構あって、頻繁に呼ぶ関数で大きい配列にmemset
なんてやった日には目も当てられない状況になります。 今日一日やってなんの成果もないのは寂しいのもう少し頑張ろう、って日付変わってるけどね。 |
|
キラームーブ実装と、局面進行関係の関数を高速するつもりでしたが、その前にハッシュ関数が
うまく実装されてないみたいです･･･。乱数の取り方がまずいのかそれ以前にやり方が間違って
いるのか全然分からん。とりあえず精度のよい乱数で試してみるか。 そういえば私のページをリンクしてくださるサイトがあるようなのですが、紹介文に 「水平線効果に関する論文」とか何とか書いてあった気がしたのは 気のせいでしょうか？ここにはそんなものはないですよ(^^;) |
|
ハッシュテーブルを実装し高速化を図る。結果は… はえぇ〜、かなり速くなりました。枝刈りが効率良く行われるように なったみたいです。この調子でどんどん高速化していきましょう。 |
| 来年のコンピュータ将棋大会に向けて今日から製作を再開しようと思います。 今までの製作スタイルではとてもじゃないですけど上位陣には追いつけそうも ないので今年一年間本気で製作に励むつもりです。 |