Monitoring the recursive growth of a zombie rabbit population
Comments on your code:


I’m surprised by the requirement that the input to answer() has to be a string, not an int.

Since an int seems to be the natural input, I’d put most of the processing code in a separate function that only deals in ints, and do the string mangling at the very far edges of the program. Something like:

def answer(str_S):
    result = answer_from_int(int(str_S))
    if result is None:
        return None
    else:
        return str(result)


That allows you to separate the processing logic from the (somewhat unusual) interface.
There are no comments or docstrings in your code, which means that


I don’t know what it’s supposed to do, and
I don’t know why you wrote it this way.


Knowing either of those would make the code substantially easier to read, review and maintain. Get into the habit of writing comments and docstrings – when you’re debugging your old code, you’ll thank yourself for it.
Choose more descriptive variable names. You can usually find more appropriate names than single characters, and the result is significantly more readable code. It’s much easier to follow the control flow if I’m following names instead of letters.




Comments on your approach:

You’re right, this won’t scale. You’re caching a huge number of results, most of which aren’t used. I did some quick experiments, and found that \$R(n) \approx 2n\$, which means that a 10^25 lookup is going to require a dict with 10^25 entries. Ouch.

You’re building up to find \$S\$, even if \$S\$ is huge. We can approach it much faster.

Here are a few suggestions:


Computing a single value \$R(n)\$ only needs a small subset of the values \$R(1)\$ to \$R(n-1)\$. By using the recurrence relations, you can get to it in very few operations (I think O(log n).)

So rather than computing and caching every value you might need, only do that for the results you actually need. This will result in significant occupancy and processing savings.

But how do we know which values of \$R(n)\$ we should look at?
Let's split the sequence into odd and even results, which I’ll define with the notation
$$R_O(n) = R(2n) \qquad R_E(n) = R(2n+1)$$
Since all \$R(n)\$ are positive, both of these sequences are monotonically increasing. Further note that \$R(n) \geq n\$ for all \$n\$.

As such, I know that if there is some \$n\$ such that \$R(n)=S\$, it must have \$0 \leq n \leq S\$. So we can do a binary search in the odd/even subsequences for \$S\$, and quickly find out whether it’s in either of the sequences (and then which has the larger value of \$n\$).


Here’s a skeleton class I wrote that allows me to efficiently compute zombit counts. The code isn’t complicated, so you can try filling it out:

class Zombit(dict):

    def __init__(self):
        # set up the initial values

    def lookup(self, N):
        # Get the value R(N), either from the cache or by computing from
        # the recurrence relations.  Remember to cache the result!


I can use this to look up \$R(6\cdot10^{300})\$ in a fraction of a second and with minimal occupancy. You’ll easily be within the bounds of the question, and then some. (Trying to go higher, I ran into Python’s max recursion depth.)

Setting up the binary search is a bit harder, but still not too complicated.