A weakly complete sequence is a sequence *a*_{1}, *a*_{2},
*a*_{3},... of positive integers having the property
that there is a number *N* such that every integer larger than *N* can be
written as a sum of terms
of the sequence. For example, the sequence

is weakly complete with

11 = 10 + 1,

12 = 12,

13 = 12 + 1,

and so on. While this is a nice example of a weakly complete sequence, in some ways it's not very interesting. One reason why it's a bit boring is that it's pretty obvious that the pattern above for representing numbers will continue, and that all the integers bigger than 9 will be represented. Another reason is that we have lots of numbers very close together (all the numbers after 1 are only 2 apart from the next number), and we have some numbers in the sequence that we don't really "need". For example, we don't really need to have the number 22 in the sequence because we already can represent this as 22=10+12.

My rule to generate these sequences is to only add numbers to the sequence when we need to have
them. More formally, my rule is:

**RULE:** Let the initial terms *a*_{1}, *a*_{2}, ...,
*a _{n}* of the sequence be any increasing sequence of distinct positive integers
you want. Then,
if

For example, suppose that we decide that the initial terms of the sequence should be 1 and 5.

Since 6=1+5, we do not need to add 6 to the sequence.

But we cannot write 7 as a sum of terms 1 and 5, and so we add 7 to the sequence. So the sequence
now begins 1, 5, 7.

Since 8=1+7, we do not add 8 to the sequence.

We cannot write 9 as a sum of terms from 1, 5, 7, so we have to add 9 to the sequence. The
sequence now begins 1, 5, 7, 9.

Since 10=1+9, we do not add 10 to the sequence.

We cannot write 11 as a sum of previous terms, so we have to add it to the sequence. So the
sequence will begin 1, 5, 7, 9, 11.

Since 12=1+11, we do not add 12 to the sequence.

Since 13=1+5+7, we do not add 13 to the sequence.

Since 14=5+9, we do not add 14 to the sequence.

Since 15=1+5+9, we do not add 15 to the sequence

And so on....

If we continue like this, the sequence that we eventually get is:

Notice that in this sequence, there is a pattern to the terms. The terms seem to fall into "blocks" of two numbers that are close to each other, only 2 apart (9 and 11, 29 and 31, 269 and 271). Moreover, if you look at the numbers between the terms in each block, you find a pattern there too. These numbers are:

10 = 10 * 3

30 = 10 * 3

90 = 10 * 3

270 = 10 * 3

2430 = 10 * 3

and so on.

It turns out that this pattern continues forever in the sequence. Let me write the blocks of the
sequence a little differently, as follows:

Write the terms 9, 11 as 10 * 3^{0} + {-1, 1}.

Write the terms 29, 31 as 10 * 3^{1} + {-1, 1}.

Write the terms 89, 91 as 10 * 3^{2} + {-1, 1}.

Write the terms 269, 271 as 10 * 3^{3} + {-1, 1}.

So the formula for each block of the sequence is the same except for the power of 3, and these
powers are just all the positive integers.

By calculating lots of sequences like this, it looks like you get similar patterns no matter what
initial terms you choose. The specific numbers in the formulas might be different --- you might
have a different number instead of the 10, or a different number instead of the 3, or a different
set to add instead of {-1, 1}. In fact, the set might have more than 2 elements in different
examples. But in every example I've ever tried, I've found that you get a pattern similar to
this one, and that you get a similar formula for the numbers in each block.

So the problems I'd like to answer here are:

Michael Paul, a student at Loyola, worked with me on this project during the summer of 2008 as a participant in the Hauber fellowship program. To describe his work, I will write the elements in each block of the sequence as

Additionally, Mike spent some time looking at sequences where the first two terms can be any numbers. He found that the "right" way to look at these sequences is to think about the first two terms as being

Finally, Mike wrote a program in java to compute these sequences from initial values input by
the user. Currently, the program can only be run (as far as I know) using the program
jGRASP. Eventually, I hope that a student will convert it to an applet so that I can link this
page to it.

Click here to read Mike's final report for his project.