### Random Post

### Recent Posts

### Recent Comments

### Archives

### Categories

- article (11)
- enigma (1,158)
- misc (2)
- project euler (2)
- puzzle (40)
- site news (44)
- tantalizer (42)
- teaser (3)

### Site Stats

- 177,972 hits

Advertisements

Programming Enigma Puzzles

30 May 2012

Posted by on **From New Scientist #2867, 2nd June 2012** [link]

From a box of counters numbered 1 to 12, Joe asked Penny to select a set of six and place them on the corners of a regular hexagon and then place the remaining six counters on the mid-points of each side, so that the number on each of these counters was the sum of the numbers on the counters on the two adjacent corners. Joe then produced 16 counters and asked Penny to repeat the challenge, but this time selecting a set of eight and placing them, and the remaining eight, similarly on an octagon.

In the first case, Penny found her choice of the set of six counters was rather limited. How many choices did she have?

And how many choices did she have in the case of the octagon?

[enigma1700]

Advertisements

%d bloggers like this:

The following Python program runs in 44ms.

Solution:For the hexagon Penny could choose from 4 different sets of counters. For the octagon there are no sets of counters that will give a solution.Here’s a slightly modified version that additionally uses the fact that the two lowest numbers must be vertices, and the two highest numbers must be edges. It doesn’t run noticeably faster, but running it under

cProfilereveals that the number of function calls goes down from ~5500 to ~2900.It also uses a

Counterobject to track both the number of solutions and the number of different sets of counters used on the vertices in those solutions.Hi Jim,

Here is my solution:

I get a different answer compared with your code – I am doubtful that your line of code:

ss.add(‘ ‘.join(map(str, sorted(vs[:-1]))))

should sort the vertexes in compiling the set of solutions as I think the vertex order matters.

Brian

I agree that in the hexagonal case there are 6 different solutions, but in two cases the solution uses the same collection of counters as two of the other solutions. Which in a strict reading of the problem means there are only 4 possible sets of counters that can be chosen to solve the first part of the problem.

Good point Jim, I didn’t read it that way but it does look as if that is what is intended.

Here is a corrected version of my code:

The sum of the counters on mid-points = 2 x sum of the counters on the corners, so the sum of counters on corners is 1/3 of the sum of all counters.

For 12 counters, the sum of all counters is 13×6 (a multiple of 3).

For 16 counters the sum of all counters is 17×8, not a multiple of 3, so we don’t need to write any code for this option.

Also, (as Jim observed), 1 and 2 must be on corners, 11 and 12 must be on mid-points.

So, a bit of code:

I am taking the view that permutations that are not reflections or rotations of each other count as different choices, e.g. 2, 5, 6, 4, 8, 1 is different to 2, 8, 4, 5, 6, 1, hence the answer of 6 rather than 4.

Initially I also gave 6 rather than 4 as the answer but I think Jim is right that the answer to the actual question posed in this enigma is 4, the number of different sets of vertex counters, irrespective of their order.

I think you are right, as otherwise the count would need to include rotations and reflections as well as other permutations of vertex counters.

As a variation here is a recursive solution. It’s quicker than using

itertoolsfor larger values of n. For example it finds 12932 solutions (556 different sets) when n=12 in under 20s. (My other algorithm took over an hour before I stopped it).Here are the results for values of n from 2 to 18:

Good work Jim!.