« 2004年11月 | トップページ | 2005年1月 »

2004/12/30

両面塔子重視版評価関数作成ほぼ終了

両面塔子への変化の枚数を考慮にいれた評価値をはじき出す評価関数を作成した。ほぼ出来上がってるがもう少しテストしてみる必要はありそう。
ざっとテストして、既存の目先の有効枚数重視版と打ち方が異なる箇所を見つけてみたが、非常に微妙な違いでどちらがいいのか断言が難しい局面が多かった。プログラム以前に私自身の雀力をなんとかしないといけないが、こればっかりはすぐには解決できないだろうな。。。

総ステップ数:5712

| | コメント (0) | トラックバック (0)

2004/12/28

両面ターツ数えあげメソッド作成

現在の手牌のうち、完成メンツ数+両面ターツ数(フリテン待ちはカウントしない)を数えるメソッドを作成。

ちなみに、両面ターツへの変化の枚数を数える方法は、以下の手順できるとおもっている。
1. 現在の手牌の向聴数をチェック。
2. 1の向聴数よりも1つ悪い向聴数になるように、手牌をメンツ候補に分ける。
3. 2の分け方で向聴数を上げる牌リストアップ、その牌を追加したときの両面ターツと完成メンツ数をカウントする

総ステップ数:5556

| | コメント (0) | トラックバック (0)

2004/12/26

期待値計算完了

期待値計算版完了。今度こそ正しいだろう。ここまで長かった。ブログのバックナンバーで調べると開始したのが10日だから、15日もかかったのだな。少しモチベーション落ち気味だったのもあるが、思ったより難解だった。
なお、検証中ペンチャンの処理に2箇所も間違いを発見し、修正した。
exceptValueApp2

今後は、リャン面ターツへの変化の枚数を数え上げるメソッドを作成する。

| | コメント (0) | トラックバック (0)

2004/12/24

期待値計算修正中

さらにあらさんとメールでやり取り中。
先日判明した期待値計算の誤りについて説明するEXCELシートとシミュレータプログラムを作成。あらさんにメールで送っておいたところ、返事をいただいた。あらさんは私がEXCELで計算したのとは別の方法で計算する方法を示したくれた。結果は同じ数値になる模様。一人麻雀練習機のバージョンもUPしてもらった。まだ試してないが、あらさんのメールを読む限りでは、今度は正しい値を示しているようだ。
私自身のほうはまだプログラム作成中。期待値計算クラスの単体テストで確認している最中だが、1向聴までは同じ数字をしめしているのを確認した。おそらく大丈夫だろう。明日以降アプリ本体と組み合わせて検証する。

この期待値計算アルゴリズムどうせ一人麻雀の強さ向上という点ではあまり効果は無いだろうと作成前から思っていた。さらには、既にあらさんが作成しているため、いわゆる車輪の再発明になってしまい意味無いとも感じていた。そのため、正直なかなか作業意欲が湧かず思うようにはかどらなかった。でもまあ、こうして数年間だれも指摘しなかった計算ミスが解決したのだから追試験を行なう程度の意義はあったのだと思い込むことにする。

| | コメント (0) | トラックバック (0)

2004/12/23

細かいとこ修正中

期待値計算の修正にむけてこまごまとした修正を実施。期待値クラスを作って計算メソッドをプレイヤークラスから移行。その他、一発、天和、Wリーチなどの処置を追加。

総ステップ:5415

| | コメント (0) | トラックバック (0)

2004/12/21

原因判明

期待値計算の間違いを概ね理解した。結局私のもあらさんのも間違っている模様。
テンパイの時の期待値計算のときに使う見えていない牌の枚数を常に120枚計算している。実際は1順目にテンパイのときは120枚、2順目のテンパイの時は119枚と変えてやらなければいけない。これでシミュレーションで行なった数字をぴたりと一致する。しかし、EXCELでの検算はできたもののプログラム化するのはどうしたらいいのか。却ってゲームの木で手牌の変化を構造化して1万回くらいのシミュレーションをかけるようにしたほうが楽かもしれない。

| | コメント (0) | トラックバック (0)

2004/12/20

混乱中

ここ数日あらさんにメールでやり取りをしていました。
あらさんがプログラム上怪しいところをみつけ一人麻雀練習機のversionをしてくれたんですが、却って数字が合わなくなってしまった。いままでのV0.09では一向聴のときは私のプログラムと同じだったんだが。。。
うーん。。。。
あらさん曰く、一人麻雀練習機はかなり頑張って作ったそうですが、あまり反響もなかったし、もう古いプログラムで覚えていないそうです。
自分で計算してみるしかないか。
しかし2向聴から和了までの手順って意外なほど大きい組み合わせ数になります。手で(っていうかEXCELで)検算するのはかなりつらいものがある。

| | コメント (0) | トラックバック (0)

2004/12/19

期待値計算デバッグ中

作成した期待値計算版の評価関数のデバッグ中。ひとつでかいバグを発見し修正。
反復子のやり方が変だった。っていうか、有効牌をツモる前の段階の情報を入れているvectorと有効牌を積もったあとのvectorを間違って処理していた。変数名のつけ方を工夫したほうがいいかも。

さらに検証してみた。検証には「あらのHP」で紹介されている一人麻雀練習機を使っているんだが、2向聴だと数字が合わない。なんか、あらさんの方が間違ってるような気がする。例えば以下の手牌
debugging_except_value

上は残り18ツモあるとする場合の期待値は2124.58であり、これは私のアプリもあらさんの一人麻雀練習機も一緒になる。ただし下の手牌だと私のは1513.06、あらさんのは2130.72になる。どう考えても上の手牌と下の手牌では上のが期待値が高いはずだと思う。うーん、メールして聞いてみようかな。。。

| | コメント (0) | トラックバック (0)

2004/12/18

期待値計算埋め込みほぼ終了

期待値計算版評価関数作成がほぼ完了。これでテンパイ速度と点数の高さのバランスをとった捨て牌の選択を行えるようにもなる。フリテンになりそうなターツを残すか落とすかなどの判断にも活用できるはず。
しかし、今のままだと一人麻雀ならともかく4人麻雀にした際には、やや点数の高さを重視しすぎている感があるので4人麻雀化した際にはある程度補正をかける必要があると思う。

明日以降この評価関数について、もう少しテストする。
その次は両面ターツへの手変わりの枚数を数え上げるメソッドを作成する。

exceptValueExcel

exceptValueApp


総ステップ:5193

| | コメント (0) | トラックバック (0)

2004/12/17

期待値計算埋め込み中3

引き続き期待値計算ロジック埋め込み中。テンパイ状態では正しく計算できていることを確認した。
あともう少しで終わるだろう。なんとか今週末には終わらせたい。
総ステップ数:5117

| | コメント (0) | トラックバック (0)

2004/12/15

期待値計算埋め込み中2

引き続き期待値計算を再帰的評価関数に組み合わせる作業中。
なんかあまり気が乗らず作業少なめ。
一方で脳内ではリャン面ターツへ手変わりする有効枚数の数えるアルゴリズムを考え中。

やりたいことはいっぱいあるけど、何せヘタレプログラマなんでなかなか目先の作業が進まない。

総ステップ数:5146

| | コメント (0) | トラックバック (0)

2004/12/13

期待値計算埋め込み中

先日作った期待値計算のサブルーチンを評価関数に埋め込み中。
いつもそうだけど、はじめる前は簡単だと思うんだけど、やってみると結構大変。なかなか思うように進まない。

総ステップ数:5093

| | コメント (0) | トラックバック (0)

2004/12/12

期待値計算ロジック作成

期待値計算用のサブルーチンを作成。
あとは再帰的評価関数への組み込みをどうやってやるのか考える必要がある。
総ステップ数:4995

| | コメント (0) | トラックバック (0)

2004/12/10

3万局検証結果

目先の向聴数を向上させる牌の数がもっとも多くなるように牌をきるアルゴリズム(A)と現在の向聴数を向上させる牌の数×向聴数N-1の時の向聴数を向上させる牌の数×…と掛け算をすることによってもとまる評価値を基準にどの牌を切るかを決めているアルゴリズム(B)で、どの程度の差が出るか試してみた。(まだ、局数が十分とはいえないかもしれないが。)

結果は以下のとおり。

アルゴリズムA
試験数=10000
和了率=21.12%
テンパイ数=51.55%
所要時間 49932.296000秒[秒/一万局]

アルゴリズムB
試験数=20000
和了数=22.04%
テンパイ数=49.90%
所要時間 25329.500000[秒/一万局]

なお、アルゴリズムBを適用しているのは2向聴からであり、それ以前についてはAと同じである。また、Bのほうがはるかに複雑な処理をしているのに所要時間がAより短いのは、Aが高速化する前の手牌解析サブルーチンを利用してるためである。

BはAよりも和了率は1%弱ほど良くなっているが、むしろテンパイ率は悪くなっている。
テンパイ率が悪くなるのは将来の効率のために目先の効率の悪さを多少目をつむっているためであり、十分予測できる結果ではある。たとえば、11月27の記事の上の手牌では3ピンを切るより4萬をきる方がテンパイまでたどり着く確率は確かに大きいだろう。

また、和了率が1%程度の差が出るであろうこともある程度期待していた結果どおりではある。
評価関数を目先の受け入れ枚数ではなくBのような掛け算で求めること自体は間違いではないだろう。

今後の改善点の候補の1つとしては、以前紹介したあらのHPのように、向聴数毎の評価値を受け入れ枚数とするのではなくしっかりと確率計算をすることがある。しかしこれは直感的/経験的に和了率に響くほどの差がでることは考えにくい。ただし、今のままでは異なる向聴数の手牌同士の優劣の比較が行えないという欠点があり、それが解消されるというメリットはある。

もう一点の改善点候補は、手変わりを考慮に入れることである。おそらく、こちらのほうが和了率への影響は大きいだろう。アルゴリズムBは2向聴の状態から和了状態まで向聴数が上がるツモに関しては完全に網羅してるわけだが、向聴数が上がらない手変わりについては考慮されていない。

こんご、今よりも和了率を良くしようとしたら。

A.アルゴリズムBに手変わりを考慮に入れた再帰呼び出しによる先読みを実施する。
B.アルゴリズムAに、向聴数が向上する枚数以外に現在の手牌状況のあがりやすさを示す評価値を導入する。などの方法が考えられる。

A.の方法はまず間違いなく計算量的にゲームに組み込めるだけの速度を出すことは不可能だろう。
B.の方法では何を評価値として採用するか、その評価値の重み係数をどう設定するかが重要になってくる。

いずれにせよ、向聴数の変わらない手変わりを考慮に入れるために、向聴数は上がらないが両面ターツの数が増える牌を探すアルゴリズムを作っておいて損は無いだろう。

また、2つのアルゴリズムで具体的にどのような局面で打ち方に差が出たのかを今後検証してみる価値もあるかもしれない。

| | コメント (0) | トラックバック (1)

2004/12/09

検証中

再帰的評価関数検証中。
見ているかぎりではだいぶよくなっている感じがする。ただどうもやはりペンチャンターツと3445形の選択などで違和感を感じる。また、当然ではあるが、フリテンと点数計算が考慮に入っていないのが気になる。

ちなみに既存の目先に向聴数を上げる牌の個数が一番高くなるように牌をきるアルゴリズムで、
1万回検証した結果は以下とおり。

試験数=10000 和了数=2112 テンパイ数=5155 非テンパイ数=2733
49932.296000秒

実は再帰的評価関数も検証していたのだが切る牌のロスの計算を間違ってアルゴリズムにいれていたために、再度今晩やり直す羽目に。

| | コメント (0) | トラックバック (0)

2004/12/07

高速化版再帰的評価関数そこそこ完成

再帰呼び出しを利用した評価関数の作成がひとまず完了。これで11月27日に書いた上の形でも思ったとおりの牌を切るようになった。ある程度デバッグもしてあるけれど、念のため明日以降もう少しテストしておく。
その後は、リャン面ターツへの変化の枚数をカウントする関数を作るか、それとも先に4人麻雀として遊べる形にするか、まだ決めていない。
総ステップ数:4681

| | コメント (0) | トラックバック (0)

2004/12/06

評価関数高速化作成中

引き続き、評価関数高速化処理部作成中。もうちょっとで終わりそう。あと1,2時間作業すれば形になるかな。
っていうか気合いれてやれば今日中に終わったんだろうけれど、この作業はマッタリがモットーなんであまり頑張らないことにしてる。
総ステップ:4657

| | コメント (0) | トラックバック (0)

2004/12/05

自動モードと評価関数高速化作成中

流局か和了するまで自動で動作するモードを作成。
1000回ループを2セット実施したところ和了回数は185と212回だった。一人麻雀での和了率19.85%は立派な数字だと思える。(2000回では試行回数はぜんぜん少ないが)

また、現状手牌の状態記録方法として、単純にどの牌を何枚持っているかを記録している状態(A)と、メンツ、ターツ、トイツに分けて記録している状態(B)とがあるが。評価関数で再帰呼び出して先読みするときに、1つの牌をつもるごとにA状態からB状態への解析処理をしているのを止めて解析状態に牌を追加できるようにするための処理を作成中。


automode

総ステップ数:4615

| | コメント (1) | トラックバック (0)

2004/12/02

根本的な部分に単純バグ発見

このプログラムの根幹ともいえる箇所に単純なバグが見つかった。手牌を面子のセットに分析する箇所で牌の数のカウンターの減算を2重にやっていた。長すぎるメソッドの一部を別のメソッドにした際に、間違って削除しそこなったのだろう。いままでこんなバグを見つけられなかったのはホント恥ずかしい。もっとちゃんとテストしなくては。
なお、このバグ修正でだいぶ速度も改善された見込み。

総ステップ数:4409

| | コメント (4) | トラックバック (0)

デバッグ用処理、環境構築など実施

再帰的評価関数の作成の前にデバッグ用のメソッドの作成とソースの整理を実施。
また、ソース管理用にCVS環境を整えた。

総ステップ数:4401

| | コメント (0) | トラックバック (0)

2004/12/01

まだ再帰的評価関数作成中

私は麻雀の組み合わせ数を侮ってしまう傾向があるようでたびたび性能問題で悩まされる。

再帰的評価関数のアルゴリズム高速化処理実施中。手牌解析部分の処理で無駄な組み合わせを刈り取る処理を追加した。かなり高速化したがまだ遅い。あと5倍は早くしないといけない。
やはり先日のパート2でやるしかないのかもしれない。でも本当に手牌解析処理がボトルネックなのだろうか。手牌解析以外にボトルネックがあるとは考えにくいのだが確証がない。C++Builderで性能のボトルネック箇所をチェックするツールがあるとだいぶ楽なんだが。Linuxに持っていってgprofを利用することも考えないといけないのかもしれない。

総ステップ数:4400

| | コメント (0) | トラックバック (1)

« 2004年11月 | トップページ | 2005年1月 »