I'm bad at probability...Follow

NO YOUR STUPID

Try under the couch. All kinds of things can get lost down there.

I'm not misinterpreting the numbers. And they are "valid" in that they generate exactly what the script intends. My point is that what the script is doing isn't really what most people want to know when running it. See. I read the script and know exactly what it's doing. It runs a million iterations. Each time through it randomly assigns the prize to the door, randomly determines your starting pick, excludes the first non prize containing door not picked, and then randomly picks between the remaining two doors.

It's giving you the breakdown of what happens if you change your pick half the time and don't change your pick the other half. Which is *not* what you just wrote:



See how you are misinterpreting the data? The script does not tell you your odds of winning based on a given selection. It tells you how often out of a set in which you randomly change or don't change your mind various outcomes will occur. That is not remotely the same.

If you change your mind, you will win 66% of the time. If you don't change you mind, you will win 33% of the time. Those are your "odds of winning".

The fact that you misunderstood the results is because of precisely that poor output I talked about. I saw it, you didn't.



This is completely wrong. You've failed to understand what the data means. Seriously. Go back. Look at what the script is doing. And then think about it for about an hour or so. It might just come to you what you're doing wrong here.



This part you got right, which is why I'm scratching my head that you don't understand what's wrong with the first part. Since the test data basically includes half cases where you change your pick, and half where you don't. The actual odds on each pick are twice as high as those presented in the output (which is what caught my eye as being odd about it). You're correct that the point of this script is to show that your odds double if you switch versus if you stay, but the way the output is formatted makes it seem like the base odds aren't nearly as good as they actually are.

A better way to have tested this (and how I would have written the script) would be to run a large sample of tests in which the initial pick and placement of the prize are random each round and the script always change your pick, and a second set where you always keep your pick. Output the win percentage for each of those two and you'll get 66% and 33% respectively. The third line of output is completely meaningless and should not even be there. What it tells us isn't relevant outside of the methodology of the test itself.

Your overall odds of winning if you do this many times and change half the time and don't change half the time is 50%. Your overall odds of losing therefore are also 50%. But this is meaningless because the question isn't "what are my odds if I do this a million times and randomly decide to change or not change my initial pick?". The question is "what are my odds in this round, right now, if I change my pick versus if I don't?".

Just in case anyone's still confused about the problem with that script (and why the output is misleading), I'll try to explain in a bit more clear manner:

The output that reads "% of time door change resulted in a win: " is telling you how many times out of all the iterations, that this outcome occurred. It's simply counting up the total number of times out of X iterations that a door change resulted in a win. Why this is misleading is that since the odds of a door change is 50%, then half of the iterations don't involve a door change (door change is random, right?). Thus, in half of the iterations there is a zero chance of a door change resulting in a win. Out of the half in which the door is changed 66% of them resulted in a win. But the script does not calculate "winning odds" by dividing the number of wins when changing the door by the number of times the door was changed. It simply reports the percentage of time is happens out of the entire set. So since half the set does not involve a door change, the number is half as large as it would be if we were calculating the "odds of winning if you change your door".

Imagine we run just 100 iterations, the breakdown might look like this:

1. Door changed, results in win: 33
2. Door changed, results in loss: 17
3. Door unchanged, results in win: 17
4. Door unchanged, results in loss: 33

All the script is doing is giving you the results of lines 1 and 3, and then adding up lines 2 and 4 to show how many loses there were. But this is really meaningless output. What we want to know is the odds of each choice winning. To do that, we should divide line 1 by the sum of lines 1 and 2, then divide line 3 by the sum of lines 3 and 4, and output those results. This gives us how many times a given choice won or lost out of the number of times that choice was made.

When we do that we get 33/50=.66, and 17/50=.34. Which is the correct "odds of winning" for each choice.


It's a classic case of someone writing a script without really thinking through how he intended the output to be used. It's technically correct because he doesn't say that the output represents the odds of wining. But many people will make the mistake that this is what they're getting. You have to do additional math to get those odds (and have data that isn't presented in the output, like number of times that one choice was made versus another). What's really interesting in this case is that he actually had to significantly increase the complexity of the script in order to make the output less useful and more likely to be misinterpreted.


It's a bit of a pet peeve of mine, because I see this sort of mistake in programing all the time. Many coders are very good at the technical part of their craft, but fail a bit at the human factors part. It's great that he came up with a fairly clever way of manipulating the numbers assigned in his array so as to minimize loops, variables and assignments ( a nice clean "single pass" script). But he should have spent more time thinking "what are people going to use the output for?". That would have radically changed how he approached the whole thing.