Listen With Others

Although I solved this quarter’s numeric puzzle, I’m not sure that I did it in the intended way — or that I know what the intended way actually was.

Arden gave us 37 clues in the form of positive integers that each encoded a pair of distinct positive integers, either as a sum (ie the pair was A and B, and the clue was A+B) or a product (the clue was AxB). The answer in each case was (AxA)+(BxB). The challenge was therefore to find each pair A/B. I started with the shorter grid entries and lower clue numbers, for which I could enumerate the possible pairs. For example (and here I’ll give the possible values of A and B, and their corresponding grid entries):

6a: “7 (2)”. 1+6 -> 37; 2+5 -> 29; 3+4 -> 25; 1×7 -> 50.
7d: “13 (2)”. 1+12 -> 145; 2+11 -> 125; 3+10 -> 109; 4+9 -> 97; 5+8 -> 89; 6+7 -> 85; 1×13 -> 170.

Eliminating the three-digit answers from 7d, we can see that the answer must be 97 as the first digit must be the same as the last digit of 6a (which is therefore 29). So far, so good! But this gets harder to calculate by hand as we progress. A number N has about N/2 distinct sum-pairs A+B, plus a few for its factors — so 1a (“150 (3)”) has 80 possible answers, and 13a (“32984 (5)”) has 16507! So this puzzle became, to me, a game of “look for possible entries in long lists”, where the lists were not well-known sequences but had to be calculated. I didn’t relish that thought so I turned to my computer and wrote a short Python script containing all the clue details, which spat out the number of possible answers for each “N (answer length)” clue:

[user@ listener]$ python l4516.py
#  1a:   150 (3) -     3
#  3a:   220 (3) -     2
#  6a:     7 (2) -     4
#  9a: 23994 (5) -     3
# 10a:   137 (5) -    51
# 11a:    57 (4) -    29
...

I told my script to print all the options if I gave it a particular clue number:
[user@ listener]$ python l4516.py 1a
# 1a: 150 (3) - 3 results:
325
661
925

The puzzle was then a simple jigsaw, starting with the clues with only one possible answer (27a and 12d), and then filtering other answers by the way they intersected with entries I already had. Soon enough I spotted that all the entries had been prime and was able to finsh the ambiguous entries. (Not quite the very end, but I got lucky in trying the main diagonals first for the two 9-digit primes, and their respective A/B pairs were easy to come by.)

I feel like I’ve cheated a little here, but I really don’t know what a solver was supposed to do. It’s possible I missed a trick in the enumeration of A/B pairs — perhaps it was easy to spot bounds which would have given the wrong number of digits, thus reducing the search space significantly. Perhaps I could have used the anagrammatically eponymous Pierre de Fermat’s theorem on the sum of two squares — but we don’t find out that the entries are all odd primes until near the end.

So I return to my other feeling, that this boiled down to looking up numbers in big lists, and to that end I think that asking a computer to make those lists was a fair approach for those with both computer access and the relevant skills. And I can say I’ve leveraged my intelligence to get the puzzle solved, by spotting an essentially brute-force approach and implementing it without spending weeks on the calculations; humans make tools, and that gives us an advantage. But I’d really like to know what I should have done!

Thanks Arden for an interesting journey, which I enjoyed despite my worries over whether I did it fairly.