Limiting memory usage while keeping score

Question

For an assignment we are asked the following(simplified) :

A function F(a) has a non-negative integer as a result. This result is reused in the function itself. Like this, and where the first a is given:

new_a = (c1 * (previous_a or first_a) + c2) mod c3

Write, in C#, a sufficiently fast and memory efficient algorithm that tells how many iterations of the function does it take before new_a is within a specified range of any previous ones?

Now I have already made a "naive" solution as follows: I create an array of size c3 and for every new_a I check whether its corresponding index is set to true. If so, the number of iterations is returned. If not, the index and the given range around it is set to true. This goes on until there is a hit.
This solution is very fast but the downsize is that for large enough sizes of c3 there is just not enough memory available.

I have been thinking about a week now on how to solve the memory problem, but I just am stuck figuring out how to do it? The only thing I can think of is that given the function there is some kind of assumption I should/can make about the distribution of its outcomes but I just am stuck.

Any ideas on the direction I should take?

Answer 1

Your idea of an array of size $c_3$ is a good one. But you can do better. First, since you need only be withing a range $r$, you can use an array of size $c_3/r$, rounding upward, and just mark the entry corresponding to the integer segment you fall in (there may be some details to work out).

Then, rather than using an array, if it is still too large, you can build a binary structure, so that you create only the array entries you need. Each node of the binary structure corresponds to a range of consecutive entries.

Then, you can reduce the memory requirement further by merging contiguous ranges where all entries have been hit, and rebalance the tree.
Of course, there is a $\log_2 c_3/r$ price in access time. But this cost is limited by the tree shrinking as it gets full.

Answer 2

While babou offers one possible solution, that one depends on $c_3/r$ not being too large. If it is large, then you might approach the problem like this:

A data structure for solving this problem would need to provide us with 3 (or 5) operations: we need to be able to add numbers, given a number we need to find the predecessor (next smaller number) and the successor (next larger number).

One possible data structure that supports these operations is a binary search tree, and this gives a quite straightforward algorithm: generate the numbers $\{a_n\}$ one-by-one, and insert them in to the tree, and after each insertion query for the successor and predecessor values of the newly inserted number to see if they are in the specified range. If you use a balanced binary search tree (such as an AVL tree or red-black tree) each operation takes $O(\log n)$ and you obtain an $O(n \log n)$ algorithm where $n$ is the number of iterations before $\{a_n\}$ comes in to the specified range. Using a Van Emde Boas tree you could improve this to $O(n \log \log n)$. This approach uses only $O(n)$ memory so it is much more efficient than babou's approach if $c_3/r$ is large.

Another approach that is remarkably simple and might work very well in practice is based off insertion sort: if you could keep the elements of $\{a_n\}$ generated so far in a sorted array, given a new value $a_n$ you could find its position in the array using binary search and find the next larger and smaller values just by looking one position to the left and right. The problem with this approach is of course inserting new elements, since that requires expanding the array, and moving over all of the elements larger than the newly generated one one spot to the right.

However, you could store $n$ elements in an array of size $2n$, doubling up every element. You could still use binary search to find a new element's position, but inserting it becomes possible without extra work: you can simply have it take the place of a duplicated element. Of course, as the array gets fuller (with less duplicates) collisions might happen where you need to insert an element at a position where there are no more duplicates. This can be resolved in a similar manner to insertion sort, you can push elements to the right to make space for the newly generated element. Unlike insertion sort, this pushing stops much earlier: as soon as a duplicate element is encountered.

If the elements of $\{a_n\}$ are distributed somewhat evenly (which they are, by virtue of the way they are generated) then the chances of needing a long (and expensive) move step are small, and most insertions will be dealt with quickly. As the array becomes too full such collisions will become more frequent. When you get to the point where (say) the number of distinct elements stored becomes $1.5n$ you might double up the size of the array to $4n$. Even though this is a very expensive step (it requires moving all of the elements to a new array) it only happens very infrequently (since you double the size of the array each time, you only do this expensive step $O(\log n)$ times).

As I mentioned before, babou has already provided a hint in the right direction of how you can make the array smaller, this answer is just to offer a more complete solution to the problem (in case somebody ever comes along and needs guidance on how to solve this problem in a more practical setting without bounds on $c_3/r$). It's not the one you are intended to use, though if you managed to implement either one you would probably really impress the course staff and really get me in trouble :-)