Some remarks on Complements

Following Sudipta Das (see the Ed Pegg's page at mathpuzzle.com/) we define the n-complement of a number j as the number k such that corresponding digits of j and k always add to n. We want to investigate some properties of the n-complements in two special cases for the terms j, k: Let us sketch an idea that apply to the general problem (not only to our two cases). Forbidding initial zeros on the representation of our numbers, we assume that j, k have the same numbers of digits, say d; then we must have:
Main Formula: j+k=n*S where S=111...1 is composed by d times the digit 1.
Of course carries could appear in the sum j+k, thus solutions of the new problem could fail to solve the original one; but for the new formulation many interesting properties will be quite immediate.

Square-Complements

Some trivial cases

Of course any choice of x, y between 0 and 3 will give rise to a solution corresponding to a suitable n; thus we get trivial solutions for 10 values of n = x2+ y2 say (choosing x £  y and sorting the results with respect to n):

x 001 212 312 3
y 011 222 333 3
n 012 458 91013 18

Of course we could do the same work concerning the two-digit-cases (say: x, y both between 4 and 9), but it would be a quite tedious work, and a better idea could be to ask the computer to do that. In fact, as we will show in a moment, we would waste our time: no two-digits solution can exist.

A little bit of theory can save a lot of time...

Let us start from the "main formula" (in our case, say with j=x2, k=y2) and remark that, once d has been fixed, we can easely find some factors of the part S (the parts "thus n*S has the factor..." will be explained in a moment):

Let us explain the special role played by the numbers 11, 3, 271, 7, 239, 79. In general there is no relationship between the factors of x, y and the factors of x2+ y2 (consider e.g. the example 72+52 = 74 = 2*37); however in some cases a very strong connection exists: special factors of the sum must divide both x, y; so that also the square of the factor divides the sum. This happens in particular for each one of the values 11, 3, 271, 7, 239, 79; of course, with respect to the representation given in the main formula, some terms could divide n instead of the string of ones.

For other values of the factor f the result can fail; e.g. when f=13, as shown by the example 22+ 32=13.
The proof in the case f=3 is quite immediate: we fix x=3*u+j, y=3*v+k (with j, k = 0, 1, 2) thus, for the sum of squares, we have x2+ y2 = 9*(u2+ v2)+ 6*(u*j+v*k)+ j2+ k2; then the sum can be a multiple of 3 only if j2+ k2 is a multiple of 3; and this can happen only if both j, k vanish.
The general case will require to check if, with respect to the modular operations in Z/(fZ) no sum of squares can vanish. Of course this could be done through a computer-program; for factors "not too big" already JavaScript can be used to investigate this problem; Netscape users can try by clicking ; on other browsers a faster version running with bigger numbers is given .
Let us summarize the consequences of our theory: also by using a Computer search, we must fix a reasonnable bound on the number of digits; e.g. working with numbers having at most 15 digits, we can confine our search to the cases:

... But a more complete theory can give better results.

A computer search in the framework of a numbers with more than 15 digits could require a lot of time. Later on, in the framework of triangular-complements, we will show another argument of modular arythmetic that could shorten the task; but, concerning the case of square-complements, following Luke T. Pebody we can stop here our search: other solutions (if any) are out of reach, because they must be with n=11, d=2h with an exponent h>10.

Triangular-Complements

Now let us consider the problem:
Tria(x)+Tria(y)=n*S (S=111...1, d digits 1)
where the notation Tria(z) is a shorthand for z*(z+1)/2 (again, as for the square-case, we start without take into account possible carries).
At least for small values of d we could try a computer-search based on a "brute force" approach: for any x, y between 1 and some Max, we check if the value of Tria(x)+Tria(y) has the wanted form n*111...1.
A faster method could be based on the following idea: for any x in the given range, we check if the quantity [(n*111...1)-Tria(x)] is a triangular number. This requires to check if a second degree equation has integer solutions, thus we need to extract a square root; it is a lengthy operation, but the task is no doubt shorter than the cycle in y.
Modular arithmetic can help to further accelerate our program: we do not need to check for all values of x, because we can exclude "a priori" some of the values. E.g, let us consider the case of n=3; we claim that numbers x of the form 3*h+1 can not give rise to solutions. Denoting by "%3" the reminder modulo 3, from the equation Tria(x)+Tria(y)=3*111...1 we get that Tria(x%3)+Tria(y%3) must be a multiple of 3; we only need to look at the values Tria(z) for z=0, 1, 2; and from Tria(0)=Tria(2)=0, Tria(1)=1 we conclude that the remainder 1 is forbidden.
The case of n=5 can be treated in a similar way: the values of Tria(x) for x=0, 1, 2, 3, 4 are given by 0, 1, 3, 1, 0; thus we can now work only with number x of the form 5*h, 5*h+4. On the other hand we can use the "length" d of S: if we ask for n=3, d=5 (or conversely: n=5, d=3) we can mix the results, checking only the values x of the form 15*h, 15*h+4.

Based on these ideas, I wrote a JavaScript program that treates the case n=9 for numbers up to 15 digits; its speed competes very well the speed of brute-force-approaches written in faster languages. Taking into account that:

do the following:
  1. Fix the maximum number of digits
  2. Choose between or leading 0s.