*All archives* |  *Admin*

<<06  2017/07  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31  08>>
親子別のリーチ発生率その2・テスト
昨日の続き。
リーチ発生率を親と子で別々にした効果がどうでるか。

150530-01.png
自分が愚形リーチ・他家3人は不聴面前の状態の時の他家からの追っかけ発生回数を追ってみます。(各巡目10000回のシミュレーションから。)

序盤の先制リーチなら親の押さえつけ効果は高いという結果が出ました。
1000回弱の差(先制リーチ1回あたり0.1回の差)が出ています。

一方、中盤ならあまり親の押さえつけ効果は高くないです。

おそらく、1番追っかけリーチがかかりやすい先制リーチ直後(経過0順)のところの数値が、
中盤なら対親リーチでも十分高くて、その分の影響が出ているのかなぁと思います。

150530-04.png
追っかけの発生のタイミングを追ってみてもその傾向が見えますね。

序盤なら先制リーチから時間がたってから追っかけが発生する回数が多く、追っかけの総数も少ないです。

一方、中盤以降だと追っかけ発生のタイミングは先制リーチ直後に集中しています。
全体の半数くらい。
リーチかけた瞬間に追っかけられて寒い!というのが多いのがここからもわかります。10回に2回は即追っかけが来ると。

150530-02.png
150530-03.png
全体の和了率や放銃率。

あまり親の場合も子の場合も変わらないですね。

いじったのが、リーチ発生率だけで、他の数値(鳴き発生率やダマ和了率とか)は変えてないし、そもそもリーチ発生率の親と子の差が微妙にしかないので、全体としては今のところそんなに影響がないという感じでしょうか。
スポンサーサイト

コメントの投稿

Secret
(非公開コメント受付中)

コメント

いつもありがとうございます。

順位率のシミュレーションも修正する予定はないでしょうか?
残り局数と四人の点数状況ごとに和了率などを設定してシミュレーションするイメージです。

ご検討をよろしくお願いいたします。
Re: タイトルなし
> 順位率のシミュレーションも修正する予定はないでしょうか?
> 残り局数と四人の点数状況ごとに和了率などを設定してシミュレーションするイメージです。

今のところはとくには考えてないです。

現状、オーラスについてのみ、各順位ごとに別の和了率に変更できるような仕組みは作ってあります。
(親と子は別々の和了率にしています。)

オーラス以外では順位が違っても全体の和了率への影響度が少ないこと、
順位以外(上位・下位との点差等)の影響を考慮するのはデータ量的に大変そうなこと、
といったことが念頭にあります。


「オーラスの和了率補正とラス回避」
http://epsilon69399.blog20.fc2.com/blog-entry-312.html
「両面4ハン手リーチorダマその3・オーラス順位補正加味」
http://epsilon69399.blog20.fc2.com/blog-entry-313.html
「オーラスの挙動その5・トータル和了率と点数」
http://epsilon69399.blog20.fc2.com/blog-entry-284.html

以上の記事も参照していただけると幸いです。
5000点刻みとかでもパラメータは膨大になりそうで、安定もしなさそうですね。
シミュレーション結果に対する納得性は、できるだけ現実に沿った形・過程で計算されているかがポイントだと思うんですが、仕方ないですかね
補足ですが、上記に挙げていただいた記事は読ませていただいております。オーラス以外についても同様のシミュレーションを行い、それらの結果を積み上げた場合、全体として影響があるのかどうか不明ということです。
残り局数と点棒状況と、平均順位率・平均点数の関係により、和了率・和了得点を用いずに、シミュレーションすることもできそうで、その場合にはパラメータを減らすことはできそうです。点棒状況は2500点刻みとかにせざるを得ないと思いますが。
Re: タイトルなし
> 補足ですが、上記に挙げていただいた記事は読ませていただいております。

失礼しましたー。

> オーラス以外についても同様のシミュレーションを行い、それらの結果を積み上げた場合、全体として影響があるのかどうか不明ということです。

試しに残り局数と順位別の和了率(親子別)を取ってみると、

子和了率 トップ 2位 3位 4位
1 0.24276411 0.21218716 0.191663086 0.138107942
2 0.218583883 0.21442926 0.198519643 0.182785661
3 0.215105362 0.204365463 0.210220891 0.188230994
4 0.214322692 0.211105198 0.196343821 0.191983122
5 0.215070341 0.212322615 0.201780415 0.199492386
6 0.213130915 0.199738477 0.202723404 0.200360419
7 0.208584035 0.20861233 0.209970198 0.205212289
8 0.211339564 0.208333333 0.198324022 0.218113208
親和了率 トップ 2位 3位 4位
1 0.279005525 0.269951794 0.266550523 0.262392597
2 0.246328754 0.255022321 0.256911666 0.258321274
3 0.24323084 0.248303167 0.246183206 0.258339248
4 0.245859404 0.259341885 0.266369994 0.263815789
5 0.240034291 0.256262042 0.246341463 0.229519774
6 0.257091562 0.245663385 0.239240506 0.28244898
7 0.238260321 0.256259205 0.244025157 0.260954236
8 0.239096463 #DIV/0! #DIV/0! #DIV/0!

オーラス(残り局数1)では、順位による影響はかなり大きいですが、
それ以外の残り局数(残り2~4局あたり)でも、子については多少差が見受けられます。

ただ、あんまり数値は安定してないです。

現状の方式

次局以降、残り局数関係なしの以下のパラメータ(次局以降上がり方)、

親ツモ和了率 子ツモ和了率 子→親ロン和了率 親→子ロン和了率 子→子ロン和了率 流局率
0.086613218 0.071360237 0.052055964 0.045318781 0.04391071 0.143717577

に従って、和了の形態を定めて、点数を上下させる。
親和了等の連荘or親流れの別で残り局数や積み棒を変動させる。
終了条件(残り局数-4未満or残り局数0~-3で30000点に達している人がいるor持ち点マイナスの人がいる。)に従ってシミュレーションを終わらせる。

オーラスのみ(5-2*(その人の順位))*(和了率補正)分だけ次局以降上がり方のパラメータを上下させる。(和了率補正はプログラム外部からの入力としている。)


をどうゆう風に変えるかは思案のしどころです。

今のところは保留にさせてください。すみません。
ご回答ありがとうございました。

Nisiさんは、アウトプットの量がとてつもなく多く、毎回驚愕しているのですが、何かコツみたいなものはあるのでしょうか。例えば、牌譜であれば、後から色々な分析をしやすいように、データベースの作り方・設計を工夫しているとか、ありますでしょうか。
Re: タイトルなし
> Nisiさんは、アウトプットの量がとてつもなく多く、毎回驚愕しているのですが、何かコツみたいなものはあるのでしょうか。例えば、牌譜であれば、後から色々な分析をしやすいように、データベースの作り方・設計を工夫しているとか、ありますでしょうか。

牌譜の分析については、mjscore形式のテキストを順番に読み進めていくような感じで、特にデータベースを意識しているわけではないです。

たいていの関数・変数はすでに構築済み・宣言済みなので、毎回の分析では関数を1個だけ追加するとか十数行くらいプログラムを書いたり消したりする程度なので、そこまで負荷は大きくないです。
(難しいところはすでに過去にやっていることが多いし、ある程度収集しやすいデータばかり扱ってるというのもあります。)
自分ひとりで作ったもので、毎日のように分析をやってて慣れてるので、どこに必要な関数・変数があるか、どのように使うのが適切か、プログラムの流れがどうなってるか等が全部わかってるのは大きいですね。

ただ、他の方がプログラムを読んで理解できるかはわからないです。
コメントで注釈をつけてるのが最小限で、若干クセがあるのは自認してますし。

局収支等のシミュレーションについても、
出来合いのものを動かして結果を掃き出すだけなら数分で終わりますし、
出来合いのものではできないケースも牌譜分析と同様、十数行書き加えるとかいらないところをコメントアウトするとか程度の作業量なのでそこまで大きな手間ではないです。(さすがに全体の改造になってくると時間を食いますが。)
これも宣言済みの変数・関数の使い方を全部理解できているからできる芸当ですね。

一般的なシステム設計がどのようなものかはあまりわかってませんが、
個人製作で比較的小規模で過去分がちゃんと蓄積されていて自分にやりやすいようにできているのが大きいです。
他の人と共同で作るもっと大規模なものだと、いろいろとフォーマットが決まってたりして、こんなに簡単にはいかないような気がします。
プロフィール

nisi5028

Author:nisi5028
FC2ブログへようこそ!

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
FC2カウンター
フリーエリア
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QRコード