toto BIG

BIGのキャリーオーバーが約78億までいっちゃってる。 BIGはJリーグ14試合の結果を、 1:ホームチームの90分勝ち 2:ホームチームの90分負け 0:その他 の3つのパターンで番号を振って当選番号が決まるので、当選番号のパターンは3の14乗で4,782,969通りにもなる。投票口数はだいたい500万ぐらいのようなので、投票が完全にランダムなら1回につき1等当選が1口出るぐらいというところ。過去10回で1等当選が11口なので、まあ妥当ですね。 BIGの投票番号はコンピュータがランダムに決める。だが、そこで気になっているのが、ランダムでいいのか?ってとこ。 一度にたくさん投票しているわけではないので、感覚的なものになってしまうのだが、0・1・2が満遍なく現れるように番号が生成されているような感じがある。ランダムなんだから当然なんですが。 でも、試合が引き分けってそんなにあるのか? 過去10回の当選番号はこんなん。
0 0 0 2 1 1 1 1 0 2 2 0 0 1 0 1 2 1 2 1 1 2 2 2 1 1 1 2 0 1 1 1 0 1 1 1 1 0 0 2 1 2 2 2 2 1 2 0 2 1 1 0 1 0 0 1 0 2 2 0 1 0 2 1 1 2 2 0 2 1 1 2 1 1 2 2 0 1 2 0 1 1 1 1 2 1 2 1 2 1 1 1 2 1 2 1 0 0 2 2 1 1 0 2 2 1 1 0 2 0 0 2 0 0 1 1 0 2 2 1 1 2 0 2 1 0 2 2 2 0 1 2 0 1 1 0 0 1 1 1
0:36個、1:59個、2:45個。思ってたより偏りが小さい。 10試合だけだとサンプルとしては不十分だけど、ホームで勝つのが多いのはなんとなく納得できるが、それも気になるほどの差ではない。 0は引き分けや試合中止になるわけだが、これが一番少ない。感覚的には引き分けはもっと少なそうな気もするが、それは延長で試合に決着がつけられるから。BIGは後半終了時点での結果を使っているので、引き分けが最終的な試合結果より多くなる。 それでもなぜ0が少ないのかの考察は置いておこう。 投票番号の分布は一定だが当選番号の分布には偏りがあるとすると、当選確率が下がると思うのだが、当選数からするとそこまでは言えなさそう。やっぱり、もっと集計サンプルを増やさないと何とも言えないか。

コメント

このブログの人気の投稿

ORACLEのCHAR型とPostgreSQLのchar型は似て非なるもの

Tomcat10 + log4j2

XBox360コントローラドライバのせいでコア分離セキュリティが有効にできない場合