The puzzle goes like this:
- With just a fair coin, can you generate a 1/3 chance event?
Believe it or not, this puzzle actually comes from trying to address a real world application, but one that is unlike anything you would expect. You can read about it here.
There may be more, but we thought of two practical solutions.
1. The straightforward or engineering way
All we can work with is heads (H) and tails (T), but that’s actually a lot. If you think about it, all of our modern technology is based on combinations of two symbols, we call them 0 and 1, binary digits.
Let’s see how this would play out by considering some particular events.
- The chance of getting H is 1/2.
- The chance of getting HH is 1/4.
- The chance of getting HHH is 1/8.
In summary, for any particular event made out of tosses, the probability is . Thus we can group up some of these events to get as close as we can to . Let’s use the letter to designate the step: ; this determines the precision, or how good our approximation can be. The maximal error we can make would be if our value of interest laid exactly in the middle of a step. Naming the error we have:
meaning: as we make more tosses, we will be able to make up events that get closer in probability to our target value. Let’s see some examples.
- One toss. We can pick H as our event, which has probability 1/2. The error is .
- Two tosses. We can pick HH as our event, which has probability 1/4. The error is .
- Three tosses. We can pick the group made of HHH, HHT and HTH. Three events with 1/8 probability meaning the group has 3/8. The error is .
To know how many events you need to group up, which we designate with , you just have to divide the target value by your step and round up:
For me three tosses is already good enough. The probability we get is which is reasonably close to the target. Note that is almost like . The next we could get would be which is close to , then which is close to . But we don’t want to be tossing coins forever, so we need to strike a balance between cost (time) and precision.
One way to proceed is to set a tolerance, , the maximum amount of error you are going to admit, which implies an upper bound on , and use that to workout your number of tosses.
In my case I just thought that an error of (k=2) felt like too much, while (k=3) felt more reasonable; and actually for the case of aiming for the error is, as we said, (I think I’m okay with ). If you want more precision you can get to , where the error is almost ; at that point, it’s probably not worth it bothering with finer adjustments.
2. The precise or mathematical way
So the above works, but it always has an error, and some people, particularly mathematicians, prefer things to be exact. Can we do better? Yes!
The key is that for having a 1/3 probability, we would need 3 equally likely events, but when we toss a coin twice, we get 4. How can we get rid of one of them? Let’s say we want to get rid of TT, what we can do is, whenever TT happens, we repeat the two tosses. This means TT is no longer a possible event, because whenever we get that, we repeat the toss and replace it.
Let’s do the math. First we can see that the probability of getting TT repeatedly over attempts (each attempt is made of two tosses, ) is which (quickly) goes to 0 as grows. Thus, the probability mass of that option vanishes, and given the symmetry of the configuration, we expect that probability to distribute evenly among the remaining alternatives. Let’s check that just in case.
The probability of ending with HH was originally . But now, if we get a TT (which also has chance), we make another attempt, and thus we get another opportunity for HH, this one with chances. This occurs repeatedly so we have the following probability:
Recognising the part in the parenthesis as a geometric series allows us to get a result for the infinite sum:
And there we have it.
3. Comparing the two
So we got an exact solution, with a small caveat. There’s a non-zero probability that we will be tossing coins until the end of our lives. Unless you are on your death bed, I’m willing to bet quite strongly against that happening, but still makes sense to ask, which option is more time efficient?
Let’s workout how many tosses on average we need to be exact. We have a chance of just needing the first , then a of needing , and it goes like that as before. The expected tosses are:
So in exchange for a little bit of uncertainty we get an exact solution with the same tosses or less than we were considering before! Mathematics tends to not disappoint.
This highlights the importance of continuing to work on problems, even when you’ve found a solution, as you never know whether there’s an even better solution lying ahead. Also, having different solutions available can be useful as the problem definition varies. If we somehow needed a more complex probability like 5/124, the mathematical approach will require an unreasonable number of tosses, while the engineering one will do just fine.