Sunday Times Teaser 3280 – No Square Rolls
by Peter Good
Published Sunday August 03 2025 (link)
Clark had a set of more than one identical six-sided dice, and each die had a different positive whole number on each face. He would roll the dice and work out the total of all the numbers showing on the top faces. Clark knew that the largest possible total was 69, but it took him much longer to realise that it was impossible to roll a total that was a perfect square. The latter was true no matter how many of the dice were rolled.
In ascending order, what were the six numbers on each die?
15 Comments
Leave one →
A tighter version
Using recursion instead of combinations:
There is actually a subtle programming error in the above code which makes me wonder how it can consistently give the right result! The fix is quite simple. I’ll post it later.
Set items can appear in a different order every time you use them. But lines 12, 17 and 26 above assume that the set items will appear in inreasing order in the for statement on line 17. One of the several solutions here is to rewrite line 17:
as
Hi John, I was wondering about the programming error, I didn’t see one.
There is nothing wrong with the original line 17.
Both versions of the program cause find_dice() to be called 88 times with the same (sorted) contents of “faces”. The internal sorting order of “faces” in find_dice() doesn’t matter.
Hi Frits,
just because a programme gives a correct answer doesn’t mean there isn’t a bug. There is no guarantee that a ‘for’ statement with a set as an argument of ‘in’ will give the same order of results every time. Nor is there a guarantee that when all of the elements are integers that the ‘for’ over a set will give results in ascending order.
Here is a short example:
On my PC running Python 3.12.3 on Windows the printout is:
The first two lines will be in the same order all the time. The last two lines could change order.
I know that the order in which set elements are processed normally (when PYTHONHASHSEED
is not used) can vary.
My claim is that for this teaser the results (faces) don’t have to be in any specific order. In my opinion both code versions cover the full solution space.
Hi Frits,
the indentation has gotten extreme so I’m replying here.
set(range(start, mfv)) – ps:
is a set which when start = 2 is:
{2, 3, 5, 7, 8, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 21, 22}
Let’s say that the first number pulled from this set by the for statement is 20. 20 is one of the faces in the solution and it passes the ‘no squares’ test.
Line 26 then executes (with the variables replaced by values) giving:
yield from find_dice(20 + 1, (23,) + (20,))
so on the next level of recursion start = 21 and set(range(start, mfv)) – ps will be:
{21, 22}
Most of the possible values for the dice faces have been bypassed and no result will be found. In our current Python implementations, value retrieval for the sets dealt with by my code happen to be in ascending order but there is no saying that in the next version of Python this would still hold.
But line 17 will still find its way along the list of face values until it finds one that works. It may be inefficient in processing more of the list than it would had it been sorted but it still gets to the answer.in the end.
As far as I can tell all out of order values are consumed by lines 20..22 so line 26 only processes in order values.
Hi John,
Even If we force a random order:
then in each run always the same solution is found. The program calls find_dice the same number of times (87) in each run.
No valid “faces” combination is bypassed as lower fv values than 20 are still processed later on. You seem to draw your conclusions only from a theoretical point of view.
You can run your original program (without sorted) 10000 times (it takes 30 seconds with PyPy) and you’ll see it always prints the correct solution.
Thanks Fritz!
Good job! I’m still scratching my head as to why this works
There is another issue which is discussed here. Jim Randell got this right by using combinations_with_replacement whereas the rest of us initially used product.
For this teaser the order in which the dice are rolled doesn’t matter so the use of product on three dice rolls, for example, will produce the same result six times in different orders when one will do. This short program demonstrates the equivalence of the result:
Using a ficticious face = 0 allows one to run combinations of 3 only instead of 2 and 3, simplifying the code.
Also using combinations_with_replacements as suggested by Jim Randell and Brian.
And no longer worrying (thanks Frits) about the order in which elements are pulled from a set in a for statement.