## Chinese Remainders

### August 27, 2010

The solution is easily computed by the Chinese remainder theorem, which states that given a set of positive, pairwise coprime moduli *m _{i}*, 1 <

*i*<

*r*with product

*p*=

*m*

_{1}· … ·

*m*and corresponding residues

_{r}*a*mod

_{i}*m*, then the

_{i}*r*relations

*n*≡

*a*mod

_{i}*m*have a unique solution computed as the sum over

_{i}*r*of

*a*·

_{i}*v*·

_{i}*p*modulo

_{i}*p*, where

*p*=

_{i}*p*/

*m*and the

_{i}*v*are the inverses

_{i}*v*·

_{i}*p*≡ 1 (mod

_{i}*m*).

_{i}Here is our version of the calculation:

`(define (chinese-remainder as ms)`

(let ((p (apply * ms)))

(define (f a m)

(let* ((v (/ p m)) (b (inverse v m)))

(* a b v)))

(modulo (apply + (map f as ms)) p)))

The Chinese general had a thousand troups:

`> (chinese-remainder '(10 4 2) '(11 12 13))`

1000

We used the modular inversion function from the exercise on modular arithmetic. You can run the program at http://programmingpraxis.codepad.org/5LUl9JTa.

In testing this program, there were some calculations that failed with a divide-by-zero error. The problem arose in a modular inverse function that was stolen from a leading textbook. The book clearly states that the modulus need not be prime, as indeed it will not be in some uses of the Chinese remainder theorem, but in fact that is incorrect, and in that version of the modular inverse function the modulus must indeed by prime. The textbook authors were aware of the error, and noted the error in the errata on their website. Unfortunately, that algorithm was used in several exercises on Programming Praxis, including all recent uses of the `prime?`

function, all of which will have to be modified to use the correct modular inverse function. This is, of course, a strong reminder that borrowing code or algorithms, even from a trusted source, makes the code or algorithm your own, and you, not the original author, bear responsibility for any errors that appear.

I think there is an infinite number of solutions of the form 1000 + k * (11 * 12 * 13), for k in 0, 1, …

Cheating, with Sage:

sage: crt(10, 4, 11, 12)

76

Sage’s crt(a, b, m, n) solves the problem x = a mod m and x = b mod n

Kbob: Of course. But this is a blog about programming, not mathematics, so we seldom worry about such things.

Graham: I think something is a little bit wrong there.

I will admit that I do not understand the mathematics to how you get a single answer to this. But hopefully that is something I can figure out over the weekend.

In the meantime I can up with this function in Haskell:

module Main where

import Data.List

main :: IO ()

main = print $ x `intersect` (y `intersect` z)

where x = [x | x <- [1..50000], mod x 11 == 10]

y = [y | y <- [1..50000], mod y 12 == 4]

z = [z | z <- [1..50000], mod z 13 == 12]

Of which 1000 is the first answer, followed by 28 more.(50000 was just an arbitrarily picked upper bound.)

The obvious solution:

head $ [ a | a <- [1..], a `mod` 11 == 10, a `mod` 12 == 4, a `mod` 13 == 12 ]

Ooops! Thanks for pointing out my mistake. Serves me right for not reading clearly.

Again in Sage:

sage: crt([10,4,12], [11,12,13])

1000

In Python, an answer similar to Ramchip’s (except we need to provide an upper bound for the list, because Python doesn’t have Haskell’s nice lazy evaluation; note that 1716 = 11*12*13):

And for good measure, the same brute force logic in Fortran:

Mathematically speaking, there are infinitely many solutions. Technically, the Chinese Remainder Theorem finds us the congruence class modulo the product of the (three in this case) moduli which satisfies all three congruences, given certain restrictions. For those interested in the inner workings, I’ve found that Wikipedia is surprisingly strong when it comes to mathematics of a reasonably high level.

Here’s a Python brute force solution with lazy evaluation.

count() generates 0, 1, …

(for n in …) generates values of n that meet the remainder criteria.

The .next() method runs the generator until it returns its next (first) value.

I still say the problem is not quite specified. Nothing in the problem statement lets us determine whether the general had 1000 soldiers, 2716 soldiers, 4432 soldiers…

kbob, nice job with the lazy evaluation in Python! As for your concerns, you’re right; the CRT gives us a congruence class for a solution which consists of infinitely many integers. Thus, any integer equivalent to 1000 mod 1716 could be an answer (including negative numbers, but that wouldn’t make sense in the context of the question).

I got 408 using brute force. 408%11 = 10, 408%12=4, 408%13=0

Sam W: The remainder for the 13-rank case is 12, not 0.

This is quite old post, but I think it’s worth to note. Since result is always in form 13*k + 12, we can init k=21 and then increment by 13. First solution is found after 76 iterations, not 1000. :)

Factor command line:

car of infinite lazy list.

Redid it in FORTH using the Chinese Remainder Theorem. Includes the infrastructure for calculating the modular inverse. Didn’t know about the CRT before this…