You are currently browsing the tag archive for the ‘puzzles’ tag.

A related problem to the last post. You toss a fair coin, and keep going until the number of tails you’ve seen is *n* more than the number of heads. On average, how many times do you toss the coin before you stop?

Unlike the last problem, I don’t know the answer to this one, so I’d be interested in hearing anyone else’s approach. I believe that I have a good method for getting at the answer, but that I’m missing one crucial step that I haven’t yet been able to fill in.

I have a lot of coin-tossing problems floating around in my head, of varying levels of difficulty. Here’s one which requires some thought, but shouldn’t present too much of a challenge if you’ve seen this kind of problem before.

You start flipping a fair coin, and keep going until you’ve seen *n* heads in a row, when you stop. On average, how many times do you flip the coin before stopping?

Here’s a nice problem in probability. I like it because at first sight it seems fiercely complicated, but thinking about it in the right way makes it seem much simpler.

You have a bowl filled with *n* strands of spaghetti. You pick two ends from the bowl at random, and tie them together. You keep doing this until there are no more loose ends. Obviously, you will have made some number of loops when you reach the end of this process.

What is the average number of loops created?

Let’s play a game. I pick a number — any number at all (whole number, fraction, whatever). I then flip a coin to decide whether to add 10 or subtract 10 from it, and I tell you the result. You win the game if you can tell me what my original number was.

For example, suppose the number I picked was 31. I flip a coin, getting heads, and therefore add 10, getting 41, and that’s the number I tell you. Now you know that I picked either 31 or 51. It seems that you have no way of deciding between those, so your chance of winning the game is 1 in 2.

I contend that you can win the game with a probability of greater than 1 in 2, although I will admit that I can’t tell you how much greater the probability is.

Let’s introduce a bit of terminology. We’ll call the first number that I pick X. This is the number that you’ve got to guess. Then I flip a coin and add or subtract 10 from it, getting Y, which is the number I tell you. So we know that Y = X + 10 or Y = X – 10.

The secret to you winning the game is to pick your own number, Z, before I tell you Y. It doesn’t matter how you pick Z, so let’s just say that you have a computer program that generates a random number for you (from the standard normal distribution, if you want to get picky).

Now you play the following strategy:

- If Y < Z then you guess that X = Y + 10 (ie I subtracted 10)
- If Y > Z then you guess that X = Y – 10 (ie I added 10)

I claim that this strategy will win you the game more than half the time. To see why, we have to consider three cases:

- If X < Z – 10 then we always have Y < Z, so you guess X = Y + 10 and get it right 1 time in 2.
- If X > Z + 10 then we have Y > Z, so you guess X = Y – 10 and get it right 1 time in 2.
- But if X is in the interval [Z – 10, Z + 10] then your guess will always be right. If X = Y – 10 then we always have Y > Z, so you guess X = Y – 10, which is right. And if X = Y + 10 then we have Y < Z, so you guess X = Y + 10, which is right.

As long as there is some chance that X is in this interval, then there is a greater than 50% chance of you winning the game.

I’m flat hunting at the moment. This is possibly one of the most infuriating tasks to undertake, especially if you’re doing it in London, where the property market moves so fast that you can hear of a property coming onto the market in the morning, make an appointment to see it in the afternoon, and get a call at lunchtime to say that it’s been taken already.

But I have good news! My flatmate and I found a great place in Wapping, we’ve made an offer on it and we’re just waiting to see if that goes through. In the process, an interesting little puzzle came to light that I thought I’d share with you.

Like most two bedroom flats, the apartment we’ve seen has a master bedroom and a second bedroom. The master bedroom is better in every way — it has an ensuite bathroom, it’s about 50% larger, it looks cooler and it has a TV built into the wall. Obviously, both of us would prefer to have that room over the smaller room.

The question is, what’s the fairest way to decide which of us gets that room? We’re willing to split the rent up differently, but how should we decide on an appropriate split that leaves us both happy now and, more importantly, will leave us both happy for the foreseeable future?

Both me and my flatmate are ex-mathematicians, and thus are willing to put up with almost any amount of complicated wrangling if it means that we get to the right answer – so feel free to make it as involved as you like.

A little while back, science punk Frank Swain posted a mathematical puzzle on his blog. The puzzle can be described simply — space *n* points equally around the unit circle, and draw all possible lines connecting those points. How many triangles are there in the resulting graph?

The first couple of cases, *n = 3* and *n = 4* are easy — the answers are 1 and 8. For *n = 5* it requires a little more thought, but stand-up mathematician Matt Parker has a very clear explanation of why the answer is 35 on his website.

After that, it gets progressively more difficult to count the triangles. The diagram for *n = 6* is on the right. Try keeping track of all those triangles in your head (although CloudoidLtd has a very pretty, and easy to understand, solution for *n = 6* and *n = 7* on his blog.) The answers there are 110 and 287.

I was inspired by a comment on Frank’s blog to try a more traditionally combinatorial approach to solving the problem. The key observation is that each triangle is made up of exactly three chords. These chords can intersect at one of the points around the circle, or they might intersect somewhere inside the circle. We just have to classify the different ways that three chords can intersect to form a triangle, and then count up how many there are in each case.

**A guide to choosing**

The explanation will require that we understand how to calculate the number of ways of choosing a set of *k* objects from a larger set of *n* objects. We use the notation *(n,k)* as a shorthand for this. We pronounce it “*n* choose *k*“, and we definite it mathematically by

*(n,k) = n! / k! (n-k)!*

The exclamation mark is the factorial function, which means that we multiply together every number from *n* all the way down to 1, so that for example 4! = 4 x 3 x 2 x 1 = 24 (we also have the useful convention that 0! = 1). If you’ve not seen this before, it can be a fun exercise to try and work out why *(n,k)* has to take this form.

**Counting the triangles**

We’re trying to count the number of ways that three chords of the circle can intersect to form a triangle. Each chord involves two points around the circle, so there are only four cases to consider:

1. The chords form a triangle between three points. This is the simplest case to consider. Every set of three points around the edge of the circle contributes one triangle, so the number of triangles is simply the number of ways of choosing 3 objects from a set of *n* objects, which is (*n,*3).

2. The chords form a line connecting four points. There are (*n*,4) ways of choosing a set of four points, and for each set of four points there are four ways we can arrange the chords so that they form a triangle. So this contributes another 4 * (*n*,4) triangles.

3. Two of the chords share a point, and the third chord cuts across them. This involves five points in total. There are (*n*,5) ways of choosing 5 points, and for each set there are five ways to arrange the chords so that they form a triangle. This contributes another 5 * (*n*,5) triangles.

4. None of the chords share a point, so there are six points in total. To make a triangle we have to join opposite points, so there is only one way of arranging the chords so that a triangle is formed. This gives another (*n*,6) points.

With all of this counting done, we have a formula for the number of triangles formed by the mystic rose with *n* points, which we denote by *T*(*n*):

*T*(*n*) = (*n*,6) + 5 (*n*,5) + 4 (*n*,4) + (*n*,3).

So how does this formula stack up when we compare it to the results we already know? With suitable adjustments for when *n* < 6 (because (*n*,*k*) is meaningless when *k* > *n*) we get

*T*(3) = 1, *T*(4) = 8, *T*(5) = 35, *T*(6) = 111, *T*(7) = 287 and *T*(8) = 644.

This works for most of the cases, but the actual answers for *n* = 6 and *n* = 8 are 110 and 632. The formula overcounts by one triangle for the 6-sided rose, and it overcounts by 12 triangles for the 8-sided rose. What’s going on?

**Overcounting, and why the problem is hard
**

We can see the problem by looking at the 6-sided rose at the beginning of the post. The three chords which cut the circle in half all meet at the center. They don’t form a triangle, but our formula treats them as if they do. This is why it overcounts by 1.

It’s interesting to note that if the points weren’t *equally* spaced around the circle, but instead were *randomly* spaced, then we wouldn’t have this problem. It’s unusual for three lines in a plane to all intersect at the same point — it requires some special structure, and in this case the special structure is given by demanding that all the points lie on the vertices of a regular polygon. Injecting some more randomness into the problem would actually make it easier. The problem would be one of pure *combinatorics* — that is, just a problem of counting. Because of the additional regularity, we have made it a problem of *geometry*. Not only do we have to think about how the points are connected by lines, we also have to worry about the exact locations of the points. *This is why the mystic rose puzzle is hard!*

**Finding the intersections**

Whenever we have three or more chords intersecting at a point inside the circle, our formula is going to overcount the number of triangles, so we need to correct for this somehow.

Intersections at the center of the circle are easy to deal with. When there are *n* points, and *n* is even, then there are *n*/2 chords which pass through the center of the circle. Each set of three chords contributes one false triangle, and there are (*n*/2,3) ways of choosing 3 chords from a set of *n*/2, so we can modify our formula to:

*T*(*n*) = (*n*,6) + 5 (*n*,5) + 4 (*n*,4) + (*n*,3) – *a*(*n*) (*n*/2,3)

where *a*(*n*) = 1 if *n* is even, and *a*(*n*) = 0 if *n* is odd. This formula now gives the correct result for *n* = 6, although it still fails for *n* = 8.

A number of interesting hypotheses spring to mind, which would simplify the problem if they were true:

- The intersections only occur at the center of the circle.
- The intersections all occur along lines joining two points at opposite sides of the circle.
- The intersections all occur along symmetry axes of the rose.
- Except at the center, only three chords ever intersect at one point.

Unfortunately, none of these is true. Hypothesis 1 can be seen to be untrue if you look at the 8-sided roses in the pictures above. Around the center of the rose there are 8 points where three chords intersect. These explain 8 of the overcounted triangles. The other 4 are from the intersection of four chords at the center — every set of three chords intersecting at the center gives a false triangle, and there are (4,3) = 4 ways of choosing a set of three chords from four.

To see why Hypotheses 2 and 4 are false, we have to look at the 12-sided rose. Using the mystic rose drawer at nrich you can draw mystic roses with up to 20 points. For the 12-sided rose pictured on the right, we see that there is an intersection of 4 chords which doesn’t occur along a line joining two points on opposite sides of the circle. Damn!

To see why Hypothesis 3 is false, we have to look at the 16-sided rose. Now the three-point intersection doesn’t occur on a symmetry axis (can you see it? It’s in the top left quadrant of the picture). This means that this intersection is repeated 32 times around the circle, rather than the 16 times that we’d see if the intersection was on a symmetry axis.

One hypothesis that does seem to be true is this one:

5. When *n* is odd, there are no intersections of three or more chords.

This means that our formula should work for all odd *n*, and indeed for every *n* that I’ve checked, the formula holds. I still don’t have a proof, though!

With all of these hypotheses rejected, we have to come up with a criterion for the intersection of three or more chords of the circle, and a way of determining how many such intersections there are when there are *n* points spaced equally around the edge of the circle. This is to come in Part II of this blogpost.

My favorite kind of puzzles are those which sound like they’re going to be an absolute nightmare, but turn out to have a particularly beautiful solution. They’re even better if you don’t really need to know any math to solve them. Here’s such an example, which absolutely delighted me when I first solved it.

I presented it to two of my friends on a long train journey — one of them is a mathematician (in fact he’s a research fellow at Queens’ College, Cambridge) and the other works for a pharmaceuticals company. The non-mathematician got it first. It really is a problem that anyone can have a crack at.

First, I’ll describe a warm-up puzzle. It’s kind of a barometer for the real puzzle.

The challenge: produce a deck of cards, each with a whole number painted on it, with which you can make any number between 1 and 1 million, by picking out some of your cards and adding together the values. You should do this with the least number of cards possible.

Got that? You may want to stop reading and think about it for a second, because the solution is coming up in the next paragraph. I’ve found that computer scientists and programmers tend to get this one faster than most people — often with less than a second’s thought.

The answer is that you should label your cards with the powers of two, so that your deck starts 1, 2, 4, 8 … If you didn’t come up with this solution, the way to think about it is to figure out what cards you’d need to make each of the numbers from 1 up to 1 million. You need to be able to make 1, so you’d better have a card labeled ‘1’. Similarly you need a card labeled ‘2’. But with those two cards you can already make 3, so the next card that needs to be added to your deck is labeled ‘4’. After a while you should spot the pattern, and come up with an argument for why this will work for every number up to a million.

Now here’s the real puzzle, which is a bit more tricky, but fun to think about. I’m not going to give the answer now — I’ll post it in a couple of days.

Produce a deck of cards with which you can make any number between 1 and a million by picking cards and adding together their values, *even if you have lost one of the cards in the deck*.

The requirement that your deck is insensitive to the loss of a card makes the problem tricker to think about, but a similar approach to that described for the easier problem can work. For example, you know that you need to include two cards labeled ‘1’, so that even if you lose one of them you can still pick cards that add up to give 1.

For those inclined to a challenge, there are three levels of answer:

- Describe the deck of cards that solves the puzzle (easy, requires almost no math.)
- Prove that you can make any number between 1 and a million, even if you lose a card (not too hard, requires a little bit of math.)
- Prove that this is the minimal deck of cards that solves the puzzle (difficult, but still needs no math beyond high school.)

I learned this from my office mate, Toby Wood, but I’m not certain where he got it from. If you know, please leave a comment!

My last post, on the 17 x 17 challenge, ended with a solution to a problem which I thought sounded incredibly naïve* but which turned out to be correct. It got me thinking about a problem that I was posed when I was interviewing to work at investment banks. In fact I was asked the same question in interviews for two different banks (potential applicants take note).

It goes like this: You find yourself in a dark cave, which has three tunnels leading from it (see the crude sketch on the right). One of the tunnels leads outside, and it takes 3 hours to traverse it. The other two tunnels connect to each other, returning you to the cave, and they take 1 hour to walk down. If you choose tunnels at random each time you’re faced with a choice, how long will it take you on average to get outside?

I’m about to tell you the answer, so maybe you want to stop and think about it for a bit. The point I’m making is that even though the calculation you have to do is a bit involved (although simple to anyone who’s ever studied Markov chains) there’s a cheeky shortcut: you can get the answer just by assuming that you take each of the tunnels once, and add up the times to traverse them, getting an answer of 1+1+3=5 hours.

Is this just a coincidence? To find out, let’s generalise the problem. Now we find ourselves in a cave with *n* tunnels, of which *m* of them lead to an exit and *n-m* dump you back in the cave. Each of the tunnels takes time to traverse, for *i*=1,…,*n*, and is chosen with probability . We’ll adopt the convention that the first *m* tunnels are the ones that lead to an exit, and the last *n-m* are the return tunnels (notice that our generalisation allows the possibility that a return tunnel might take a different amount of time to traverse if we go in the opposite direction).

To work out what the average escape time is, we notice that if we pick an escape tunnel then we’re free in the time it takes to traverse the tunnel. If we pick a return tunnel, then we’ve increased our expected time to leave by the time that it took to traverse the tunnel. If the time to leave is *T*, then we write the expected leaving time as E[*T*], and

.

After a couple of lines of algebra we see that the expected time to leave is given by

or, written in everyday language:

Avg time to leave = (Avg tunnel length) ÷ (Chance of picking an exit tunnel)

That’s it! The average time to escape only depends on the average time it takes to traverse a randomly picked tunnel, and the probability of picking a tunnel which leads to an exit. It’s completely insensitive to the specifics of the problem, namely how long the individual tunnels are, and what the precise probabilities of picking each tunnel are. In the special case where each of the tunnels is equally likely, all you have to do is add up the time it takes to traverse each of the tunnels, and divide by the number of tunnels that lead to an exit.

This appeals to me because a problem which has a lot of fine detail turns out to be insensitive to the fine detail. I’d be interested to hear about other examples of this phenomenon.

* Is it pretentious to write ‘naïve’ instead of ‘naive’? Answers, opinions and furious rants on a postcard, please.