確率の勉強をやり直してみて、疑問に思い始めた件。
(ある程度、簡易に書いたつもりだけど、また対象読者が中途半端。)

よくある説明

30人の誕生日がバラバラになる確率は、「二人目が一人目と異なる確率」「三人目が最初の二人と異なる確率」・・・みたいに説明し、次の式が示される。

\dfrac{365-1}{365}\times\dfrac{365-2}{365}\times \dfrac{365-3}{365}\times\cdots\times\dfrac{365-29}{365}

疑問点

一般に P(A₁∩A₂)=P(A₁)P(A₂)となるのは、A₁ と A₂ の事象が独立である場合を言うのでした。独立でないときは、P(A₁∩A₂)=P(A₁|A₂)P(A₂)のようになるのでした。

式ではP(A₁∩A₂∩…∩A₃₀) = P(A₁)P(A₂)…P(A₃₀)のような形をしているので、独立かのように確率を求めることができそうに見える
「三人目が最初の二人と異なる事象」という言い方は最初の二人の事象が決まっている必要があって、独立とは言い難い

という訳で、途中経過を端折すぎではないかと思うのです。

解法1) 標本空間から考えて導き出す

標本空間Ω₃₀は、(1人目の誕生日, 2人目の誕生日, ..., 30人目の誕生日)=(1..365, 1..365, ..., 1..365) の積集合で、要素数は|Ω₃₀|=365³⁰となる。A₃₀自体、積集合からして直ぐに求めることが出来る。
条件を満たす部分集合の要素を全部を数え上げるアプローチとなる。

|A₃₀|
=(1タプル目の値)×(2タプル目で1タプルと被らない値)×…×(30タプル目で1～29タプルと被らない値)
= (365-0)×(365-1)×…×(365-29)

P(A₃₀)=|A₃₀|/|Ω₃₀|にそのまま代入すれば、確率が出る。

解法2) 事象から導き出す

30人の誕生日が異なる事象を A₃₀ とすると、A₃₀ ⊂ Ω₃₀ のように、
誕生日のあらゆる組み合わせΩ₃₀の部分集合となる。P(A₃₀)が求める確率である。
A₃₀の方が狭い条件であるから、A₃₀ ⊂ A₂₉ ⊂ … ⊂ A₂ ⊂ A₁ である。
また、A₃₀∩A₂₉=A₃₀ より、この根元事象に関して言えば、P(A₃₀∩A₂₉)(=P(A₃₀)) ≠ P(A₃₀)P(A₂₉) だから、独立でない。

\begin{aligned}
P(A_{30}) &= P(A_{30}\cap A_{29}) = P(A_{29})P(A_{30}|A_{29}) \\
&= P(A_{28} \cap A_{29}) P(A_{30}|A_{29}) \\
&= P(A_{28}) P(A_{29}|A_{28}) P(A_{30}|A_{29}) \\
&= \cdots \\
&= P(A_{1}) P(A_{2}|A_{1}) \cdots P(A_{29}|A_{28}) P(A_{30}|A_{29}) \\
&= 1 \cdot \dfrac{365-1}{365} \cdot \cdots \cdot \dfrac{365-28}{365} \cdot \dfrac{365-29}{365} \\
\end{aligned}

補足

とはいえ、こういう解法を書いているサイトが見つからないので、何かが間違っているのかもしれないと心配になってくる。

とりあえず、根元事象(上記のA₃₀やA₂₉)をどう定義するのか、計算の進め方は変わる。
ここで定義した事象では同時確率の公式より、独立ではなかった。ただ、出てくる数式は一般的な解法で進めた場合と一致する。

一般的に異なる人の誕生日同士は依存しあっている訳ではないから、個人の誕生日は他の人の誕生日とは独立である。
ただ、それぞれの誕生日が同じ、あるいは異なる事象となると、配列などに束ねてみてその部分集合の要素数を数え上げることになる。

例えば、29人いて、30人目を足したときに全員が異なる誕生日かどうかは、29人の時点で全員が異なる誕生日である必要があって、誕生日が同じ人達、誕生日が異なる人達で関係・グループが出来上がる。29人が全員が異なる誕生日だと分かっているグループでないと、30人目が自分の誕生日を告白したところで、30人全員が異なる誕生日にはならない。

まとめ

集合演算の基礎が重要
確率の問題はパターンを覚えれば解ける問題が色々とあるが、標本空間、独立など理解があやふやだと、どこかで詰む。

余談

位相空間あたりで分野にある開集合だとかで連続性について理解を深めると、離散確率空間と連続確率空間の関係がよく分かる
情報工学的には、ハッシュが被る確率がこれに類似する。
- Unix の共有メモリを獲得するときに使うftok()システムコールとか、キーが増えると衝突が起きまくるというものがあった。結局、キー衝突が起きる前提でキーを取り直す実装が必要で、簡易なAPIに見えて製品レベルのコードを書くときには面倒この上ない・・・という話はあった。

おまけ

Plotly でグラフ化してみた。(どのみち同じ結果になるので)計算の仕方は、再計算の手間を考えて$\displaystyle\prod_{i=1}^{N}\dfrac{365-(i-1)}{365}$ ですけどね。

<html>
<head>
  <!-- Plotly.js -->
  <script src="https://cdn.plot.ly/plotly-latest.min.js"></script>
</head>
<body>
  <div id="myDiv"><!-- Plotly chart will be drawn inside this DIV --></div>
  <script>
    let ary_x = [];
    let ary_y = [];
    let sum=1.;
    for (let i = 1; i <= 60; i++) {
        let numerator = 365 - (i - 1)
        let denominator = 365
        sum *= numerator/denominator
        ary_x.push(i);
        ary_y.push(sum);
    }

    var trace1 = {
      x: ary_x,
      y: ary_y,
      type: 'scatter'
    };

    var data = [trace1];

    Plotly.newPlot('myDiv', data);
  </script>
</body>
</html>

参考