0

This is actually more of a math question. I need to find the largest palindrome that's the product of two 3-digit numbers. For this my initial solution was a standard double loop with both i,j initialized to 999, where 'i' didn't decrement until 'j' hadn't decreased all the way down to 100. I quickly realized this method did not ensure I 'meet' the palindromes in a decreasing order like I wanted, and that instead I must decrement the indices alternately. My question is, why is that the case? I KNOW that for a product x = bc to decrease as slowly as possible, I need to decrement b,c alternately, but I don't understand WHY that is. I am looking for a theoretical explanation, be it a formal proof or something intuitive.

EDIT: after some of the comments, I feel I should re-write my question: I thought that by decrementing my indices alternatively, I would be decreasing my product by as little as possible every iteration, thus guaranteeing I meet the HIGHEST palindrome first, thus allowing for my code to finish as soon as I meet the first palindrome. Is this not the case? Thank you

felisimo
  • 198
  • 14
  • if you decrease both alternatively, you'll miss some values. I would rather nest 2 loops and naively check every combinations of `b` and `c` to keep the highest value – Cid Jun 07 '20 at 09:22
  • I don't think that there is a simple way to enumerate the products in decreasing order. Think of the simpler case of products of 1 digit numbers. 16 , 15, 14 corresponds to factors (4,4), (3,5), (2,7), but you wouldn't have enumerated index pairs in that order unless you had already factored the numbers (or found all such products and sorted them). – John Coleman Jun 07 '20 at 09:45
  • @Cid why would I miss values? And the main question is, would I miss the highest palindrome, i.e, am I not going through the products in a descending order if I go: 5x5, 5x4, 4x4, 4x3, 3x3 ect...? – felisimo Jun 07 '20 at 10:55
  • @felisimo you'll miss `5x3`, `5x2` and more – Cid Jun 07 '20 at 11:00
  • 2
    Draw yourself a wee multiplication table for single digit numbers, with `1*1` at the top left. The sequence you seek is found by starting at the position of `9*9`, then scanning the `SW/NE` diagonals as you move `NW` across the table (since the table is symmetric you can ignore either the upper or lower triangle). Your initial method is equivalent to either a horizontal or vertical scan, which you quickly realised isn't what you want. – High Performance Mark Jun 07 '20 at 11:04
  • It is a question of mathematical fact if you would miss the highest palindrome. You might get lucky. Your search strategy only searches through some products. The subset you search through might happen to contain the number you are searching for, but that is far from obvious and could probably only be verified by doing much of the work that you would otherwise avoid (you would have to consider larger products that the search missed in order to check that they didn't have palindromes). – John Coleman Jun 07 '20 at 11:11
  • @JohnColeman you're right, not only would I not go over the products in that order, but I would not go over (3,5) and (2,7) AT ALL, but does that mean there is a chance I would miss the highest palindrome? My thought was that by decrementing the indices alternatively, I decrease my product by as little as possible, thus allowing my program to finish as soon as I found the 1st palindrome – felisimo Jun 07 '20 at 11:20
  • But the fact that you are often skipping over values means that you are *not* always decreasing the product by as little as possible. For example, sometimes successive numbers are products, so that decreasing as little as possible would be going from `b*c` to `b*c - 1`, but both `(b-1)*c` and `b*(c-1)` would be much smaller than `b*c - 1`. – John Coleman Jun 07 '20 at 11:24
  • Show your code that you think generates all products of 3 digit numbers in (weakly) decreasing order. It's not clear what you mean by "decrement b,c alternately" to produce all products, since there's no obvious way that can work. – Paul Hankin Jun 07 '20 at 11:49
  • 1
    The decrement `b,c` approach as a matter of fact will skip over the maximum palindrome (since that palindrome happens to have `b,c` with `|b-c| = 80` but your method never gives `|b-c| > 1`) – John Coleman Jun 07 '20 at 11:55
  • As a practical concern, running the program that tries all pairs with b<=c takes 5 or 6 ms on my machine (in straightforward C). – Paul Hankin Jun 07 '20 at 12:04
  • There's a discussion about this problem here, https://stackoverflow.com/questions/29932870/optimizing-the-largest-palindrome-from-product-of-two-three-digit-numbers (my answer, which I can't now easily follow :), offers a solution in 375 iterations + 100 for pre-processing). – גלעד ברקן Jun 07 '20 at 13:01

1 Answers1

2

If you alternately decrease b and c in x = bc then you will go through 2*900 = 1800 pairs rather than 900^2 = 810000 pairs. Not all of those 810000 pairs lead to distinct numbers (less than half do (227521 to be precise), both because b*c = c*bbut also because factorization into non-primes is not unique). Your alternating strategy misses the majority of products.

There is no simple way to enumerate products in decreasing order. For example, in the case of products of 1-digit numbers if you tried to enumerate pairs (b,c) with b <= c in order of decreasing product, this would be the iteration order:

enter image description here

No simple loop indexing will get you that. You would need to factor the numbers or enumerate all such products and then sort. In either case, this will be less efficient than a straightforward brute-force iteration using standard nested loops.

Note that the above picture will look different if you sorted slightly differently. I formed a 45x3 matrix where the last column was the product and sorted the rows according to that product in decreasing order. But, there are numerous ties in that column e.g. 24 = 3*8 = 4*6. When there are ties, different sorting algorithms might give different sorts. Resolving the ties differently might get you a nicer picture, but it will never give you a simple picture.

Community
  • 1
  • 1
John Coleman
  • 51,337
  • 7
  • 54
  • 119
  • so what you're saying is that there's no "escape" from going through all possible products of any two 3-digit numbers and saving the highest one, and also, that there's no advantage in going over the numbers from top to bottom (999 -> 100) ? – felisimo Jun 07 '20 at 11:30
  • 2
    @felisimo Relatively few numbers are palindromes. Enumerate the palindromes of the requisite size in reverse order (should be easy enough). Factor them until you get one which is the product of 2 3-digit numbers. – John Coleman Jun 07 '20 at 11:40