ある母集団のランダムなメンバーが別の母集団のランダムなメンバーよりも「良い」確率をどのように推定できますか？

2つの異なる母集団からのサンプリングがあるとします。各メンバーがタスクを実行するのにかかる時間を測定すると、各母集団の平均と分散を簡単に推定できます。

ここで、各母集団からの1人の個人とのランダムなペアリングを仮定した場合、最初の人が2番目の人よりも速い確率を推定できますか？

具体的な例を念頭に置いています。測定値は、AからBへのサイクリングのタイミングであり、人口は私が取ることができるさまざまなルートを表しています。次のサイクルでルートAを選択する方がルートBを選択するよりも速くなる確率を計算しようとしています。実際にサイクルを実行すると、サンプルセットに別のデータポイントがあります:)。

私はこれがこれを解決しようとする恐ろしく単純な方法であることを知っています、特にどんな日でも風が他の何よりも私の時間に影響する可能性が高いので、私が尋ねていると思うなら教えてください間違った質問...

probability normal-distribution

— アンドリュー・エイレット
ソース

これは、単純な二項検定を介して行うことができます。@ Macroには良い答えがあります。ただし、1つの問題はサンプル自体にあります。ルートAまたはルートBを選択することに影響を与える可能性のあるものはありますか？特に、道路が乾燥していて、風があなたの後ろにあり、夕食が待っているときに、ルートAを取るのが好きですか？:)いずれかのセットの外れ値に影響を与えたり、何らかの方法でサンプルにバイアスをかけたりする可能性のあるものには注意してください。たとえば、変化する必要性（安全性など）を考慮して、事前にサンプリング計画を設定してみてください。

— イテレーター

もう1つの考慮事項：手段が非常に似ている2つのルートがあり、どちらも高速になる確率の点で他のルートを支配していないとします。たとえば、1つは常に10分または20分であり、もう1つは常に正確に15分です。より大きな不確実性（例えば、標準偏差）にペナルティを科すか、ある閾値よりも短い時間を要する可能性がより高い不確実性を優先する方が良いかもしれません。あなたの質問は現状のままで問題ありません。私は単に将来の改良を提案しているだけです。

— イテレーター

統計的な質問は問題ありませんが、ルートが速くなる確率を計算する場合は、ルートの長さを測定することをお勧めします。地形が起伏していない場合、短いルートは常に高速になります。

— mpiktas

風が重要な要因であり、風速が2つのルートに関連している場合、質問に正確に回答するにはAとBの依存関係に関する情報が必要であると思われます。そのためには二変量データが必要になりますが、同時に2つのパスに乗ることは困難です。データを収集するために他の人を登録することもできますが、ライダー間のばらつきを考慮する必要があります。AとBが独立している場合、以下の答えは素晴らしいです。

別の言い方をすると、どの道を取るか、トンネルを通るか、フィールドを通るか、風が狂ったように吹くかを判断しようとしている場合、平均的にひどく悪くてもフィールドを選択する可能性が非常に高くなります。

回答:

解決

二つの手段があるとする及びとその標準偏差も及びそれぞれ。2つのライド（の間のタイミングの差）従って、平均有すると標準偏差を $\mu_x$ $\mu_y$ $\sigma_x$ $\sigma_y$ $Y-X$ $\mu_y - \mu_x$ 。標準化された差（「zスコア」）は $\sqrt{\sigma_x^2 + \sigma_y^2}$

z = \frac{μ_{y} - μ_{x}}{\sqrt{σ_{x}^{2} + σ_{y}^{2}}} .

$z = \frac{\mu_y - \mu_x}{\sqrt{\sigma_x^2 + \sigma_y^2}}.$

乗車時間に奇妙な分布がない限り、乗車が乗車よりも長くかかる可能性は、で評価される正規累積分布にほぼます。 $Y$ $X$ $\Phi$ $z$

計算

あなたはすでにの見積もり持っているので、あなたは、あなたの乗り物の一つに、この確率をうまくできなどを:-)。この目的のためには、いくつかのキー値を記憶するのは簡単です：、、、そして、 $\mu_x$ $\Phi$ $\Phi(0) = .5 = 1/2$ $\Phi(-1) \approx 0.16 \approx 1/6$ $\Phi(-2) \approx 0.022 \approx 1/40$ 。（近似は、 $\Phi(-3) \approx 0.0013 \approx 1/750$ よりもはるかに大きいが、知ら。補間に役立つ）に関連して $|z|$ $2$ $\Phi(-3)$ $\Phi(z) = 1 - \Phi(-z)$ と補間のビットは、 1つの有効数字までの確率をすばやく推定できます。これは、問題とデータの性質を考えると十分に正確です。

例

ルートは標準偏差6分で30分かかり、ルートは標準偏差8分で36分かかるとします。広範な条件をカバーする十分なデータがある場合、データのヒストグラムは最終的にこれらに近似する可能性があります。 $X$ $Y$

Two histograms

（これらはGamma（25、30/25）およびGamma（20、36/20）変数の確率密度関数です。乗車時間に予想されるように、これらは明らかに右に歪んでいることに注意してください。）

それから

μ_{x} = 30, μ_{y} = 36, σ_{x} = 6, σ_{y} = 8.

$\mu_x = 30, \quad \mu_y = 36, \quad \sigma_x = 6, \quad \sigma_y = 8.$

ホセ

z = \frac{36 - 30}{\sqrt{6^{2} + 8^{2}}} = 0.6.

$z = \frac{36 - 30}{\sqrt{6^2 + 8^2}} = 0.6.$

我々は持っています

Φ (0) = 0.5; Φ (1) = 1 - Φ (- 1) \approx 1 - 0.16 = 0.84.

$\Phi(0) = 0.5; \quad \Phi(1) = 1 - \Phi(-1) \approx 1 - 0.16 = 0.84.$

したがって、答えは0.5と0.84の間の0.6であると推定します。0.5+ 0.6 *（0.84-0.5）=約0.70です。（正規分布の正しいが過度に正確な値は0.73です。）

ルートはルートよりも時間がかかる可能性が約70％あります。あなたの頭の中でこの計算を行うと、あなたの心は次の丘から離れます。:-) $Y$ $X$

（表示されているヒストグラムの正しい確率は、どちらも標準ではありませんが、72％です。これは、トリップ時間の差の標準近似の範囲と有用性を示しています。）

— ヒューバー
ソース

if you have iid realizations from each distribution then what is the advantage of using the normal approximation rather than a monte carlo re-sampling approach (my answer) to estimating

P (X > Y)

$P(X>Y)$ ?

— Macro

@Macro: if the data can be reduced to summary statistics for the Q of interest, one can store less data... just a thought.

— Iterator

P (X > Y)

$P(X > Y)$

Y

$Y$

X

$X$

Y

$Y$

X

$X$ .

— Iterator

FWIW: @whuber is describing Student's t-test for the difference in means between two samples with different standard deviations.

— Iterator

Thanks, @whuber, this is the answer to the question I'd been trying to ask :).

— Andrew Aylett

My instinctive approach may not be the most statistically sophisticated, but you may find it to be more fun :)

I would get a decent-sized sheet of graph paper, and divide up the columns into time blocks. Depending on how long your rides are - are we talking about a mean time of 5 minutes or an hour - you might use different sized blocks. Let's say each column is a block of two minutes. Pick a color for route A and a different color for route B, and after each ride, make a dot in the appropriate column. If there's already a dot of that color, move up one row. In other words, this would be a histogram in absolute numbers.

Then, you would be building a fun histogram with each ride you take, and can visually see the difference between the two routes.

My sense based on my own experience as a bike commuter (not verified through quantification) is that the times will not be normally distributed - they would have a positive skew, or in other words a long tail of upper-end times. My typical time is not that much longer than my shortest possible time, but every now and then I seem to hit all the red lights, and there's a much higher upper-end. Your experience may be different. That's why I think the histogram approach might be better, so you can observe the shape of the distribution yourself.

PS: I don't have enough rep to comment in this forum, but I love whuber's answer! He addresses my concern about skewness pretty effectively with a sample analysis. And I like the idea of calculating in your head to keep your mind off the next hill :)

— Jonathan
ソース

+1 For creativity. Actually, your idea is on the path toward practical utility. It would be quite a bit more interesting to use one of the biking tracking sites (I forget which one now, but do add, if you know) to track segment times. If the OP were to come back to CV or StackOverflow with a question about plotting segment time and get a density associated with it, it would be a fabulous statistical exercise - GIS, statistical visualization, and density functions, oh my! :)

— Iterator

I have used Google MyTracks on my phone to track biking segments. I find that the phone is not great at it as it tends to be a power-suck on a device not optimized for it. Garmin (and others) make GPS devices specifically targeted at runners and bikers to track time spent on routes and provide neat charts in an online interface. I don't use a dedicated GPS device myself, but some of my friends use them to share routes on facebook.

— Jonathan

Here is an example of what Garmin device produces. The problem with the charts is that they are already heavily pre-processed, smoothing, etc. Also there is no convenient way to import the data to R for example. But as dedicated device it does its job splendidly, I cannot imagine running or biking without it.

— mpiktas

+1 Note that not much skew comes from hitting the red lights (unless they are timed): collectively, they usually only add some Gaussian noise to the time distribution. (Computing its variance is another mental exercise you can do on the next hill.) In practice the skew comes from non-Gaussian variation in the few important factors that control the entire ride: weather, how you're feeling, with whom you're riding, and the occasional accident/detour/traffic jam etc.

— whuber

Now that I think about it some more, another very important factor is the time of day. The traffic lights act very differently at peak traffic times - much longer greens for the higher-traffic road. In off-peak times, the lights tend to cycle quickly, defaulting to green for the high-traffic road, but quickly changing when I press the crossing button or a car activates the sensor.

— Jonathan

Suppose the two data sets are $X$ and $Y$ . Randomly sample one person from each population, giving you $x,y$ . Record a '1' if $x > y$ and 0 otherwise. Repeat this many times (say, 10000) and the mean of these indicators will give you an estimate of $P(X_{i} > Y_{j})$ where $i,j$ are randomly selected subjects from the two populations, respectively. In R, the code would go something like:

#X, Y are the two data sets
ii = rep(0,10000)
for(k in 1:10000)
{
   x1 = sample(X,1)
   y1 = sample(Y,1)
   ii[k] = (x1>y1) 
}

# this is an estimate of P(X>Y)
mean(ii)

— Macro
ソース

This is a good answer, but you could simplify it by removing the for loop: let x1 = sample(X, 10000, replace = TRUE) and y1 = sample(Y, 10000, replace = TRUE) and then calculate mean(x1 > y1) along with mean(x1 == y1) - to get a sense of the # of times the values are equal.

— Iterator

Thanks. I knew the loop was unnecessary but I wanted the logic underlying the approach to be abundantly clear. Your code would certainly produce the same results.

— Macro