Probability and Coin Tossing

You get challenged to a game of coin toss. Both players pick a sequence of coin toss results (heads or tails). The coin is repeatedly tossed until the sequence for one of the players occurs. The loser pays the winner a dollar. You'd assume that you each have an equal chance of winning. However, using two little "tricks" you can tip the odds in your favour. The first trick is to always choose second. If you can manage this then your strategy is as follows:

Your first choice should be the opposite of your opponent's second choice.
Your second and third choices should be the same as your opponents first two choices.

The top three buttons are for player A, the bottom three for player B. You can set the choices manually by clicking the buttons. If you click on "Choose B for me" then player B will be set to the choices based on the above strategy. Each time you click "Start" a new game is played with the coin tosses and game results displayed in the listbox.

For the GUI, the top three buttons are named Button1, Button2 and Button3. The bottom three are Button4, Button5, and Button6. The remaining three controls are (buttons) btnChoose, btnStart, and (listbox) lbxResults.

When tossing a coin we can (and will) make following assumptions:
1. the result will allways only be tails or heads
2. the coin is fair i.e. the probability of tails is the same as heads, P(T) <=> P(H)
3. the coin tossing is stateless operation i.e. the coin does not and can not "remember" last result
4. from the previous assumptions follows that given any sequence of coin tossing results, the next toss has the probability P(T) <=> P(H)

Using the given strategy player B chooses a sequence: H, T and T. Tossing this sequence has the probability
P(H) * P(T) * P(T) or 1/2 * 1/2 * 1/2 = 1/(2^3) = 1/8 which is exactly the same as the probability of the player A's sequence.

From this follows that
1. using the strategy, how to choose the sequence, does not increase the probability of that sequence
2. to always choose second does not help i.e. increase the probability of the sequence

I don't know the math, but by running the code you can see that player B will win either by a little or by a lot. You can modify the code, for example, so that each click on Start playes 100 or 1000 games and check the results.

It's one of those problems where the "obvious" solution is not the correct solution. Take the following problem, for example. Let's assume, for the moment, that the Earth is perfectly round and flat. Imagine that you could build a solid ring that touches the surface at every point along the equator. The ring would be (if Google is correct) 40,075 km long. Now let's imagine that you want to enlarge the ring so that it is one meter above the surface at every point. Without doing the calculation, approximately how much material (length) would you have to add to the ring? would you guess 100 meters?, 1000 meters?, 10,000 meters? The actual answer is just over 6 meters. It doesn't seem logical but that's the answer you get if you do the math. Your common sense tells you one answer and the math, another.

Picture it this way. Imagine the Earth is a cube whose perimiter is 40,075 km, If you cut the ring at the corners and lift the four segments one meter up, all you would have to add is an arc of material at the four corners. The arc has a radius of one meter and the four corners form a circle of diameter 2 meters. The circumference of that circle is 2 * 3.1415 or just over 6 meters. But the earth isn't a cube. Well then, make it an octagon (in profile). The segments you have to add still combine to make a circle. This is true no matter how many sides you use.

Being deeply sceptical about this, and agreeing with Teme64, I hacked together a little Java version of the logic (no GUI needed), ran 10000 iterations with all 8 possible "A" choices and guess what - absolutely no consistent or significant difference in the number of wins. Here's the code in case I made a mistake...

With 3 coins you would expect a 1/8 hit rate against any given choice, as seen above.
Your results show vastly too many hits. No amount of majic will make three tosses come up THH 768/1000 times. Sorry, but I'm sure you have a bug somewhere.
Anyone else try this?

I don't speak java (luddite, I suppose). In case there is a misunderstanding about the tosses, when I do the tosses I don't generate three new tosses at each pass. i throw out the oldest toss and generate one new toss. I start by seeding three tosses (1,2,3) and compare those to both players. Then I generate a new toss (2,3,4) and compare those, then (3,4,5), (4,5,6), etc.

It looks to me that you generate three new tosses on every turn which would signficantly change the parameters of the game.

The idea (I suppose, from a street grifter point of view) is to present a game of chance that appears to have even odds but which is weighted in favour of one player.

A is looking for a,b,c
B is looking for -b,a,b
the trials are rotating as described.

For A to win you need to get a,b,c
The previous try will have been x,a,b - which B has a 50/50 chance of matching.
Ie for any sequence that is a match for A, B has a 50/50 chence of matching it on the previous turn.

Conversely for B to win you need to get -b,a,b
The previous try will have been x,-b,a - which A has zero chance of winning.

Its the rolling "random" rolls, combined with A= a,b,x and B= y,a,b that gives B the edge in matching on the turn before A can match, but not ViceVersa.

The origin of the problem is the Random object itself. Suppose our Random object outputs only 0's and 1's (just like tossing a coin gives only heads and tails). Ideally Random object would somehow output a sequence that meets the conditions

probability of 0 is equal to the probability of 1 ("fair coin")

given any output sequence of 0's and 1's the probability of getting next a '0' is equal to the probability of getting a '1'. That is, knowing any number of previously outputted 0's and 1's does not change the predictability of the next output. On the other words, Random object does neither "remember" what the previous output was nor does it use any previous output to generate next output. This would make Random object stateless (like a coin).

So, how does this Random object "produce" these random 0's and 1's? The answer is: it does not produce anything random. It produces pseudo-random 0's and 1's.

The computers are deterministic like they should be. Algorithms ("computer programs") are deterministic by definition. This is why our Random object is also deterministic and not "random" in statistical sense. When someone wrote the actual code for our Random object, he or she chose an algorith that "mimics" randomness i.e. the outputted values have as uniform distribution as possible and knowing any number of previously outputted values keeps the predictability of the next output as small as possible.

This applies to C#, Java or any programming language which has some sort of Random object or Random function. The best you can get is pseudo-random numbers.

Choosing our three heads and tails, like in the first post, may give a slightly better chance to win. But that is the result of the pseudo-randomness, the algorith used in the Random object or there may even be a bug in the Random object's code. Changing the code to Java simply changes "unfair coin" to another "unfair coin".

I'm sorry, but the "random" functions in major languages are not so terrible that they would give such significant non-random results. That's a complete red herring.

Please re-read my previous post. The first triple is random but the following sequence of triples is very highly corrolated. Any triple a,b,c will be followed by a triple b,c,x. This scam works by exploiting the correlation between successive trys. Because of the carefully chosen difference between A's and B's triples player B has a 50/50 chance of matching A's sequence one turn before A sees it, but A can never match B's sequence before B sees it.

So here are the expected odds:
A's sequence will appear 1 in 8 tries, but half of those will be captured by B in the previous round, so that's 1/16 for A and 1/16 for B
B's sequence will appear 1 in 8 tries, but all of these will be captured by B

So we would expect A to win 1/16 of the time, amd B to win 3/16.
Now here's my result from a run of 1,600,000 tries (200,000 each of A's possible sequences)

That's very slightly better for A than my analysis, but the reason is probably that my analysis doesn't apply to the first one or two tries after a win (because then there's a new random triple, and the odds are 1/8 for both players).

When I test the random number generation (for 0, 1) against ten million tosses I compare the number of each result and see only (approximately) a 0.02% difference. In any case, as long as neither player is aware of any inbuilt bias toward either a heads or tails then both players are playing by the same rules. Therefore the difference in the probability of a win for A or B is not due to a problem with the random number generation.

@James - thanks for the analysis

The generation of random numbers is too important to be left to chance.
—Robert R. Coveyou

Hi. so this is actually a continuation from another question of mine[Here](https://www.daniweb.com/programming/software-development/threads/506795/dynamically-add-values-into-datagridview-cell-from-listbox-vb2010) but i was advised to start a new thread as the original question …

I have a 2d matrix with dimension (3, n) called A, I want to calculate the normalization and cross product of two arrays (b,z) (see the code please) for each column (for the first column, then the second one and so on).
the function that I created to find the ...

I'm working in Excel to extract content of a table from a web page and populate Excel sheet cells with it. I'm trying to extract data from a table that gets loaded to a web page after show results method gets called. I have an error that says "Run-time error ...