著作一覧 |
出現確率1%のガチャを100回引いても,4割近くの人は全部はずれる。“本当の確率”を読み解いてみようを読んでいてふと疑問に思った。
なぜ
もちろん素直に当たりの確率を求める方法もあるのだが,その場合は計算式がかなりややこしくなることから,今回はこの方法を取っている。当然ながら計算結果はどちらの方法でも同じだ。
なんだろうか?
いや、確かに、誕生日の一致問題でも一致しない確率を求めて1から引くから、普通にそうなるのだけど、この場合はそれほどややこしいとは思えない。
とは言え、確率得意マンではないので、考えてみる。
最初にいきなり当たる確率は1/100。2番目に当たる確率は99/100*1/100(というかこの時点で足し算して2/100にならないのだから100/100になるわけあり得ないとふつう気付くだろうと思うが)、3番目に当たる確率は99/100*99/100*1/00……で、暗算ではできないけど、それほどややこしくもないような気がする。
あ、1~100Σ(1/99 ** n * 1/100)……ってうまく書けないからか。
とはいえ、C#なら、
using System; using System.Linq; class Gatcha { static void Main() { Console.WriteLine(Enumerable.Range(1, 100).Select(n => Math.Pow(0.99 , n) * 0.01).Sum()); // => 0.627627982139503 } }
……ボイラープレートが8行もあるが、本体は1行だ。
で有効桁は2(ここは自信がない)なんだから、0.63で確かに同じになった。
Rubyなら
(1..100).inject(0){|r,n|r+0.99**n*0.01} #=> 0.627627982139503
そういえば0乗は1だよな、と頭では考えていた(というのはしょっぱなから当たる確率は99/100**0*1/100)のに、なぜか1.upto(100)とかEnemerable.Range(1, 100)とか書いている。
当然、Enumerable.Range(0, 99)(間違い)と、0.upto(99)だ。
その場合、0.6339676587267706(C#版は0.630270362350273で、なぜこの場合は差が生じるんだろう?)だから63%というのに変わりはないけど。
ジェズイットを見習え |
Enumerable.Range(int start, int count)なので、Enemerable.Range(0, 100)が正しいと思います。(そうすると0.633967658726771になりますね)
おお、どうも。逆にRubyのuptoにひきずられたけど、.NETのAPIって、Substringもそうだけど2番目が長さでしたね。