[gopalv]

> there is also a very elegant solution that fits in a tweet. (If you don't want to try solving it, or have tried and have given up, here is the solution

I tried to understand the tweet a couple of times, but I couldn't follow the proof from the tweet itself, so I wrote it up again with the basic axiom from the tweet as a basis + work out each step of the process.

https://gist.github.com/t3rmin4t0r/a953450ac64b6868540bbce79...

The original proof is elegant, because it has a single item of information (the "what") to use to solve the entire thing, but was missing the "how" for me.

[kazinator]

Modulo 9, a decimal integer is equal to the sum of its digits. More precisely, congruent, notated by ≡:

For instance 123 ≡ 1+2+3 ≡ 6 (mod 9).

We show congruences using ≡, and always have (mod N) on the far right to indicate the modulus for the congurence.

More generally, if ABC is a decimal string, then we know that ABC ≡ A + B + C (mod 9).

Moreover ABC + DEF + GHI must be congruent to A+B+C + D+E+F + G+H+I (mod 9).

And if ABC + DEF + GHI is equal to 123J, then A+B+C + D+E+F + G+H+I ≡ 123J ≡ 1+2+3+J (mod 9).

Thus:

A+B+C+D+E+F+G+H+I ≡ 1+2+3+J (mod 9)

Now suppose we add J to both sides:

A+B+C+D+E+F+G+H+I+J ≡ 1+2+3+J+J (mod 9)

OK so now we know that the left hand side A+...+J contains all elements from 0 to 9, because of the problem constraint that the letters represent unique digits. The numbers 0 to 9 add together to 45. Now 45 is congruent to 0 (mod 9).

Therefore:

A+B+C+D+E+F+G+H+I+J ≡ 45 ≡ 0 ≡ 6 + 2J (mod 9)

We no longer care about the A+..+J; it's vanished. We solve the remaining equation:

0 ≡ 6 + 2J (mod 9)

If 6 + X (mod 9) is congruent to 0, X must be one of {... -6, 3, 12, 21, 30, 39 ...}: the set of integers congruent to 3, (mod 9).

If X = 2J, where J is a one-digit decimal integer, X must be an even, non-negative integer. That rules out -6, 3 and 21. It can't be 30, because J can't be 15. X must be 12, which gives J = 6.

[quietbritishjim]

That was all good, except this bit was not obvious to me:

> Modulo 9, a decimal integer is equal to the sum of its digits. More precisely, congruent, notated by ≡:

> For instance 123 ≡ 1+2+3 ≡ 6 (mod 9).

This is the part where the parent comment's explanation was helpful.

[kazinator]

There is a nice, succinct explanation for this (which relies on some intuition or knowledge of modulo arithmetic and congruences).

First, a small defnition: let dsum(X) denote "sum of the digits of the decimal representation of whole number x".

In the modulo 9 congruence, 0 and 9 are equivalent symbols. 9 ≡ 0 (mod 9). Though distinct integers outside of the congruence they are indistinguishable elements of the congruence.

Observe that since 9 is congruent to 0, the number 10 is congruent to 1: 10 ≡ 1 (mod 9). Therefore, all powers of 10 are also congruent to 1: 1 ≡ 10 ≡ 100 ≡ 1000 ... (mod 9).

Next, note that these numbers x ∈ {1, 10, 100, 1000, ...} all have the property that x ≡ dsum(X) (mod 9). The sum of decimal digits of each power of 10 is 1, and each power of 10 is congruent to 1, modulo 9.

Within a congruence, whenever we multiply by any congruence element that is indistinguishable from 1, we get the same element. So all of these numbers 1, 10, 100, ... are identity elements in the modulo 9 congruence.

Identity means that, for instance 7 ≡ 70 ≡ 700 ≡ 7000 = 7000 ... (mod 9). If we multiply the congruence element 7 by any power of 10, the result is congruent to 7, modulo 9, because 10 is the identity element: no matter how many times we multiply an integer by 10, the resulting integer is the same modulo 9 congruence element. (Moreover, also note that dsum(7) = dsum(70) = dsum(700) ...).

Next, note that every decimal integer is formed by a sum combination of multiples of power of 10.

For instance, 1234 is equal to 1 x 1000 + 2 x 100 + 3 x 10 + 4.

But suppose we do this arithmetic in the modulo 9 congruence: it must necessarily be that:

1000 + 200 + 30 + 4 ≡ 1 + 2 + 3 + 4 (mod 9).

This is because, individually, 1000 ≡ 1 (mod 9), and 200 ≡ 2 (mod 9), 30 = 3 (mod 9). The power of 10 factors do not matter, since they are really powers of the identity element 1 in the mod 9 congruence.

The succinct explanation is then: every whole number has a decimal form made up of digits, which are multiplied by powers of 10. But in the modulo 9 congruence, powers of 10 do not matter: they map to the multiplicative identity element 1. That leaves the sum of the digits indistinguishable (in the modulo 9 congruence) from the value of the number (which is also a kind of sum of the digits, with each digit being scaled by a different power of 10).

[kazinator]

I'm trying it with this TXR Lisp, just for fun. It uses an implementation of John MacCarthy's amb operator based on delimited continuations, which are slow.

  (defmacro amb-scope (. forms)
    ^(block amb-scope ,*forms))

  (defun amb (. args)
    (suspend amb-scope cont
      (each ((a args))
        (whenlet ((res (and a (call cont a))))
          (return-from amb-scope res)))))

  (defmacro 0-9 () '(amb 0 1 2 3 4 5 6 7 8 9))

  (defmacro val (p q r) ^(+ (* 100 ,p) (* 10 ,q) ,r))

  (compile-only
    (amb-scope
      (let* ((A (0-9)) (B (0-9)) (C (0-9))
             (D (0-9)) (E (0-9)) (F (0-9))
             (G (0-9)) (H (0-9)) (I (0-9))
             (J (0-9)))
        (amb (and (eql (+ (val A B C)
                          (val D E F)
                          (val G H I))
                       (+ 1230 J))
                  (eql 1023 (mask A B C D E F G H I J))))
        (prinl (list A B C D E F G H I J)))))

Every amb expression says: "I denote my leftmost non-nil argument which makes the remaining computation successful".

The "remaining computation" is the future computation up to returning a value from the enclosing amb-scope form. The amb-scope form succeeds if it yields a non-nil value.

We use amb to ambiguously bind A, B, C, ... to all the values from 0 to 9, amb magically selects the successful value for each one.

We also use amb to express assertions. If we assert (amb (eq 'day 'night)) then that fails: night is not day.

We simply assert the desired conditions over the variables. If there is any way for the conditions to be true, then that means there exist successful values for the variables and so all the prior ambs choose those successful values.

  This is the TXR Lisp interactive listener of TXR 272.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  Upgrade to TXR Pro for a one-time fee of learning Lisp!
  1> (compile-file "abcprob")
  t
  2> (load "abcprob")
  (0 1 2 3 4 5 8 7 9 6)
  nil

Thus

     012
     345
     879
    ----
    1236

The "all letter digits unique" is efficiently met using bits to represent a set. TXR Lisp has a mask function which calculates an integer whose binary representation has a 1 in the positions indicated by the arguments. E.g (mask 0 2) yields 6, and (mask 0 1 2) yields 7.

If mask is given 10 unique digit values---the complete set---it must produce the value #b1111111111 or 1023, the complete set mask.

We thereby avoid n squared silliness like (and (neql A B) (neql A C) ...): asserting that no letter pair is equal.

[jonsen]

Normally in these kind of cryptogram puzzles the leading digits of a number can't be 0. Your solution has A = 0.

[kazinator]

In that case, we can easily add these constraints to look for another solution, like this --- but that is a poor way:

  (compile-only
    (amb-scope
      (let* ((A (0-9)) (B (0-9)) (C (0-9))
             (D (0-9)) (E (0-9)) (F (0-9))
             (G (0-9)) (H (0-9)) (I (0-9))
             (J (0-9)))
        (amb (and (eql (+ (val A B C)
                          (val D E F)
                          (val G H I))
                       (+ 1230 J))
                  (nzerop A) (nzerop D) (nzerop G) ;; don't do this
                  (eql 1023 (mask A B C D E F G H I J))))
        (prinl (list A B C D E F G H I J)))))

Better just exclude the value 0 from the amb expression for those digits, to reduce the search space:

  (defmacro 0-9 () ^(amb ,*(range 0 9)))

  (defmacro 1-9 () ^(amb ,*(range 1 9)))

  (defmacro val (p q r) ^(+ (* 100 ,p) (* 10 ,q) ,r))

  (compile-only
    (amb-scope
      (let* ((A (1-9)) (B (0-9)) (C (0-9))
             (D (1-9)) (E (0-9)) (F (0-9))
             (G (1-9)) (H (0-9)) (I (0-9))
             (J (0-9)))
        (amb (and (eql (+ (val A B C)
                          (val D E F)
                          (val G H I))
                       (+ 1230 J))
                  (eql 1023 (mask A B C D E F G H I J))))
        (prinl (list A B C D E F G H I J)))))


  1> (compile-file "abcprob.tl")
  t
  2> (load "abcprob")
  (1 0 2 3 4 5 7 8 9 6)

So:

    102
    345
  + 789
  -----
  =1236

:)

[kazinator]

Since we have a math proof that J is 6 in all possible solutions, which works without discovering the other values, we might as well bind (J 6); the purpose is to get the other letters. Binding J cuts down the execution time by close to an order of magnitude.

[kazinator]

John's amb operator has a weakness: it is satisfied with finding one successful value. What if we want all the solutions?

We must invent a related operator. Let us call it kanzen, Japanese for completion/perfection (完全). (This is not the "kan" in "kanren" which is 関連).

amb-scope and amb are defined exactly as before, but we add:

  (defun kanzen (. args)
    (suspend amb-scope cont
      (return-from amb-scope
        (append-each ((a args))
          (whenlet ((res (and a (call cont a))))
            (list res))))))

Using only amb, let's find some pair of integers x y, in the range 0 to 9, whose product is 12:

  (prinl
    (amb-scope
      (let ((x (amb 0 1 2 3 4 5 6 7 8 9))
            (y (amb 0 1 2 3 4 5 6 7 8 9)))
        (amb (eql (* x y) 12))
        (list x y))))

The output is:

  (2 6)

Now, let's change the first amb to kanzen. Just the first one:

  (prinl
    (amb-scope
      (let ((x (kanzen 0 1 2 3 4 5 6 7 8 9))
            (y (amb 0 1 2 3 4 5 6 7 8 9)))
        (amb (eql (* x y) 12))
        (list x y))))

The output now is:

  ((2 6) (3 4) (4 3) (6 2))

all the (x y) pairs are found that multiply to 12.

What does kanzen do differently? Like amb, it cares only about non-nil arguments. However, instead of just finding the first non-nil argument for which the future computation succeeds (returns non-nil), and then returning that result out of amb-scope, kanzen probes all non-nil arguments. It continues the future computation with each value, and for each computation that succeeds (returns non-nil), it collects that value into a list. Then it aborts amb-scope using that list as the result value.

So the weird thing to be understood here is that (list x y) doesn't necessarily determine the ultimate result value of the amb-scope form. The first amb or kanzen call holds the reins, so to speak. If the first operator is amb then, indeed, the result value will be one that was produced by (list x y). amb will try the different futures, and when it finds one that yields non-nil, it aborts amb-scope with that value.

What happens with kanzen is that the ((y (amb ...))) part will find successful y values, and abort amb-scope. But it's doing that aborting within the scope of a continuation created by kanzen, so kanzen intercepts that, collects the (list x y) value, and keeps trying other futures. Thus, confusingly, the result doesn't have shape expected by (list x y).

Note how this is fundamentally hostile to static typing. This code depends on exactly the same piece of syntax, the amb-scope block, having a different type in different contexts: a list of integers during the execution of the search, and a list of lists of integers in the ultimate return.

A static typing theory could be developed for this which assigns multiple types to a node in the program. The interior of amb-scope can see its return value as "pair of integers". all the continuations captured within that scope have that return type. But because of the presence of kanzen, the node can be assigned an external static type as "list of pairs of integers". Or something like that.