First break the recursion into its logical steps: identify the base case and the repeated work. Then replace the implicit call stack with an explicit stack data structure. Push the initial state onto the stack, and loop while the stack isn’t empty. Pop a state, perform the work that would happen before the recursive call, push any new states that represent the recursive calls, and finally handle what would be the post‑recursive work. This way you keep the algorithm’s structure but avoid deep recursion. If the function is tail‑recursive, you can often simplify it into a single while loop with updated parameters. Always test edge cases after the change to confirm you haven’t altered the semantics.

Memoization is a good idea if the subproblems overlap; you just store the result in a hash table keyed by the parameters. Then before pushing a new state, check the table, and skip the work if it’s already computed. That keeps the stack smaller and the loop faster. If you run into a case where the keys grow too large or the memory blows up, we can adjust the cache or use a bounded LRU. Let me know what edge case you’re seeing, and we can step through it.

The edge case I’m seeing is when the recursion depth grows because the function keeps calling itself with very similar arguments—think of a binary tree that’s nearly balanced but has a deep left spine. The stack grows until it hits the limit, and the memo table gets bloated because each call’s key is a slightly different state that doesn’t collapse. We can sketch the call sequence and see where the memo lookup might help or where we need to prune. What’s the exact pattern you’re seeing in your input?