« 2008年6月 | トップページ | 2008年8月 »

2008/07/13

被先制リーチ時

被先制リーチ時の他家の聴牌率を集計してみる。
まだ、途中だけど、上が門前ダマ、下が1副落時のデータ

それぞれ、被リーチの順目と順目ごとに聴牌率を出してみた。
Hi_reach_4

18順目あたりをみてみると、興味深いのが、
ダマの場合は、後半にリーチされたときのほう方が聴牌率が高いけど、1副落のときは逆に序盤にリーチされたときのほうが高いこと。

まあ、ある意味これは当たり前で、
(A)リーチをされた時点で、1副落していた
(B)一発けしのために副落した
(C)一発権利消滅後に副落した
この3つではまったく意味合いが違う。当然一発権利消滅後に鳴いてきたってことは降りてないわけで相当聴牌の確率は高くなる。そして序盤にリーチをされたときのほうが当然(C)の割合が多くなる。

まあそりゃそうなんですが、だとすると、どうやって他家挙動を含めた先読みをするのか……

(A),(B),(C)で条件わけしてデータ取らなければいけないのか、そんな細かく条件わけしたらデータが足らないんだけどな……

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

2008/07/09

チートイモードの統合

まずはチートイモードを統合した。まだ、ベタオリモードを統合していないので、突っ張りまくりだけど自然な打牌をしているように見える。次は他家挙動とベタオリモードを統合する。これがまた面倒なんだが、やるしかない。
この修正がうまくいけば、局終了間際の形式聴牌とか、オリ判断とかが良くなると期待してる。


上記の作業とは別に、試しに今使っているのとは別方式の向聴数チェックアルゴリズムを作ってみた。

現在使っている奴は深さ優先探索で面子塔子対子浮き牌を抜き出していた。
今回作った奴は、ひとつのSuit分の考えうる全てのパターンをメモリに記憶して2分探索でサーチする方式。
メモリは余分に消費するけれど(6MBytes位)、速度は一万倍近く早い模様。
(また答えが正しいかちゃんと試してない。)

でも、向聴数チェックの速度よりも、むしろ、受け入れ牌列挙、捨てパイ候補列挙、点数計算、局面推移、期待値計算の速さのほうが重要で新しく作った向聴数チェックベースで果たしてそれが実現できるかどうかが疑問が残る。
うまくいけば、プログラム的にはずいぶんきれいになるんだけど……

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

2008/07/01

思い切り修正してみる

他家挙動の修正をする際、いままで、暫定的に対処していた部分がネックになりそうなんで、この際思い切って修正することにする。

まずは、ベタオリモード、通常モード、七対子モードと分かれていた評価関数のアルゴリズムを統合してひとつのアルゴリズムで処理できるようにする。

染め手モードや鳴き仕掛けモードも将来的には統合したいけれどまだそこまではできそうに無い。

これだけ大幅に修正してもそれほど強くはならないだろうけれど、今後の作業がやりやすくなるので基盤整備の意味も含めて改造してみる。

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

« 2008年6月 | トップページ | 2008年8月 »