2015-06-11(Thu)
福地 誠 氏、みーにん 氏 著の「統計で勝つ麻雀」。
ちょうど研究のキリがいいところなので、ちょっと遅れた感はありますが、感想をつらつらと書いていきます。
決して読むのをサボっていたわけではないです。
なんといっても衝撃なのは統計戦術No.8の「押し引きを切り換えろ」の項目ですよね。
そんなに局収支論って危険だったのか。
今までいろんな実戦譜からシミュレーションしてきた（そこまで数をこなしていたわけではないが、）印象では、
南2局くらいまでは押し引きで局期待値でまぁ500点くらいの差があれば、半荘収支・平均順位・段位ptで逆転するケースは少なかったような感じを持っていたのですが。
現状の局収支シミュレーションでは、局収支だけでなく、半荘収支等の半荘単位の得失も出せるようにはなってます。
でも、局収支は自分・他家の点棒状況を設定しないで出すことができるから、汎用性が高くて便利なのは間違いないんですよね。
過去に作った「押し引き表」も局収支がベースになってますし。
「先制平和のみをリーチするか」（他は無条件）みたいなざっくりしたテーマなら局収支で見るのが一番手っ取り早いです。
でも、今後は可能な限りは、半荘単位の得失にベースを持って行った方がよさそうですね。
入力条件が増えるので、めんどくさくて難しいですが。
次の項目の77ページの図1についても。
今までは、もう少し東1局の和了放銃の影響は少ないような感覚を持っていました。
ちょっと疑いがあったのと、この図なら手持ちのシミュレータで再現できるな～と思ったので、ちゃちゃっとシミュレータを動かして検証してみると。（南家スタートで北家からロン和了・北家に放銃した場合）
大体同じ感じのグラフになりました。疑ってすみませんでした。
後は大体、「うんうん、そうだよね～」みたいな感じ。
統計戦術No.3の「親の価値は連荘より高打点にあり」は総論としては同意です。
面前一向聴VS鳴き聴牌最終回・まとめで、親の方がチーテン取る巡目が遅くなる、面前有利の範囲が広いという結果が出たのがちょっと不安だったので、そこのところが論理的に補強されたのはよかったです。
（とはいえ、さすがに33ページの牌2を中盤以降も鳴かないのはやりすぎ感を感じますが。）
ただ、1点ちょっとだけ、ほんの少しだけ異論があります。
それは統計戦術No.12の93ページの表1、先制カンチャン・ペンチャン・単騎待ちリーチの上がり率のところです。
悪形だと枚数が減ると大分苦しいみたいな感じに書かれていますが、
枚数が少ない≒場に多く切れてるということは、リーチがかかった巡目が遅いところが多いんじゃないかなぁ、という考えを持ちました。
先制愚形ならば巡目が1つ違えば2～3％くらいは和了率が変動します。
ですから、平均リーチ巡目が遅いということが、枚数が少ない側に和了率の数値が不利に働いている、
同じ巡目で待ちを選択する場合（例えば1枚切れシャボと0枚切れカンチャンとか）はここに出ているほどの差は出ないのではないか、枚数差による和了率の不利度合いは緩和されるんじゃないかなぁと思いました。
手元の東風荘のデータで、切れてる枚数と待ち別に平均リーチ巡目を取ってみる（すべての巡目と5～12巡目に限定した場合）と、↓のような感じになります。
やっぱり枚数が少ないほどリーチ平均巡目は遅いですね。
1枚違うと、リーチ平均巡目は1弱程度遅くなると。
だとすると、そのリーチ平均巡目の遅れの影響で、和了率的に2％くらいは枚数が少ない側に不利に働いている、
同巡目で比べれば2％くらいは枚数差による影響はこれより緩和されるのではないかな、と思った次第です。
もちろん、2％程度の影響であれば枚数差を覆すほどではないです。根底から結論が違う、というつもりはありません。
ただ、データ数の問題から巡目別で和了率を取るのが困難なのは重々承知しています。
（実際、過去に切れてる枚数を考慮しようとした時、四苦八苦した経験がありますし。）
ところで、話は変わりますが、全部で「2600万局のビッグデータ」ってすごいですよね。
私が扱ってるのは5万とか7万局（のべ局で20万とか30万）ですから。100倍の規模です。
↑で取ったリーチ平均巡目の集計完了にかかった時間は1分半です。もし、データ量が100倍になったら150分、2時間半もかかる計算になります。これは時間がかかりそうだ。
私なんかは未熟なので、データが出力されて初めて「あ、これ違うわ、ここ修正してもう1回取り直しだわ」ってなることは日常茶飯事です。（もっとひどいときはどこがおかしいのかすらわからないことがある。）
集計にかかる時間が2時間半とかになってこんなことが起こると気が狂いそうになっちゃいます。
もし、データ量が増えたならある程度まで（例えば10万局経過時とか）集計が進んだらいったん一時的に結果を掃き出してデータをチェックする、みたいな工程は必須になるでしょうね。
ちょうど研究のキリがいいところなので、ちょっと遅れた感はありますが、感想をつらつらと書いていきます。
決して読むのをサボっていたわけではないです。
なんといっても衝撃なのは統計戦術No.8の「押し引きを切り換えろ」の項目ですよね。
そんなに局収支論って危険だったのか。
今までいろんな実戦譜からシミュレーションしてきた（そこまで数をこなしていたわけではないが、）印象では、
南2局くらいまでは押し引きで局期待値でまぁ500点くらいの差があれば、半荘収支・平均順位・段位ptで逆転するケースは少なかったような感じを持っていたのですが。
現状の局収支シミュレーションでは、局収支だけでなく、半荘収支等の半荘単位の得失も出せるようにはなってます。
でも、局収支は自分・他家の点棒状況を設定しないで出すことができるから、汎用性が高くて便利なのは間違いないんですよね。
過去に作った「押し引き表」も局収支がベースになってますし。
「先制平和のみをリーチするか」（他は無条件）みたいなざっくりしたテーマなら局収支で見るのが一番手っ取り早いです。
でも、今後は可能な限りは、半荘単位の得失にベースを持って行った方がよさそうですね。
入力条件が増えるので、めんどくさくて難しいですが。
次の項目の77ページの図1についても。
今までは、もう少し東1局の和了放銃の影響は少ないような感覚を持っていました。
ちょっと疑いがあったのと、この図なら手持ちのシミュレータで再現できるな～と思ったので、ちゃちゃっとシミュレータを動かして検証してみると。（南家スタートで北家からロン和了・北家に放銃した場合）
大体同じ感じのグラフになりました。疑ってすみませんでした。
後は大体、「うんうん、そうだよね～」みたいな感じ。
統計戦術No.3の「親の価値は連荘より高打点にあり」は総論としては同意です。
面前一向聴VS鳴き聴牌最終回・まとめで、親の方がチーテン取る巡目が遅くなる、面前有利の範囲が広いという結果が出たのがちょっと不安だったので、そこのところが論理的に補強されたのはよかったです。
（とはいえ、さすがに33ページの牌2を中盤以降も鳴かないのはやりすぎ感を感じますが。）
ただ、1点ちょっとだけ、ほんの少しだけ異論があります。
それは統計戦術No.12の93ページの表1、先制カンチャン・ペンチャン・単騎待ちリーチの上がり率のところです。
悪形だと枚数が減ると大分苦しいみたいな感じに書かれていますが、
枚数が少ない≒場に多く切れてるということは、リーチがかかった巡目が遅いところが多いんじゃないかなぁ、という考えを持ちました。
先制愚形ならば巡目が1つ違えば2～3％くらいは和了率が変動します。
ですから、平均リーチ巡目が遅いということが、枚数が少ない側に和了率の数値が不利に働いている、
同じ巡目で待ちを選択する場合（例えば1枚切れシャボと0枚切れカンチャンとか）はここに出ているほどの差は出ないのではないか、枚数差による和了率の不利度合いは緩和されるんじゃないかなぁと思いました。
手元の東風荘のデータで、切れてる枚数と待ち別に平均リーチ巡目を取ってみる（すべての巡目と5～12巡目に限定した場合）と、↓のような感じになります。
やっぱり枚数が少ないほどリーチ平均巡目は遅いですね。
1枚違うと、リーチ平均巡目は1弱程度遅くなると。
だとすると、そのリーチ平均巡目の遅れの影響で、和了率的に2％くらいは枚数が少ない側に不利に働いている、
同巡目で比べれば2％くらいは枚数差による影響はこれより緩和されるのではないかな、と思った次第です。
もちろん、2％程度の影響であれば枚数差を覆すほどではないです。根底から結論が違う、というつもりはありません。
ただ、データ数の問題から巡目別で和了率を取るのが困難なのは重々承知しています。
（実際、過去に切れてる枚数を考慮しようとした時、四苦八苦した経験がありますし。）
ところで、話は変わりますが、全部で「2600万局のビッグデータ」ってすごいですよね。
私が扱ってるのは5万とか7万局（のべ局で20万とか30万）ですから。100倍の規模です。
↑で取ったリーチ平均巡目の集計完了にかかった時間は1分半です。もし、データ量が100倍になったら150分、2時間半もかかる計算になります。これは時間がかかりそうだ。
私なんかは未熟なので、データが出力されて初めて「あ、これ違うわ、ここ修正してもう1回取り直しだわ」ってなることは日常茶飯事です。（もっとひどいときはどこがおかしいのかすらわからないことがある。）
集計にかかる時間が2時間半とかになってこんなことが起こると気が狂いそうになっちゃいます。
もし、データ量が増えたならある程度まで（例えば10万局経過時とか）集計が進んだらいったん一時的に結果を掃き出してデータをチェックする、みたいな工程は必須になるでしょうね。
スポンサーサイト
