-solve This is the most complex problem to analyze. I claim that my solution solves the given instance in O(n) time. I get this solution by analyzing my solve function in its two parts. The first part is computing the correct q using the modified pascals triangle. To compute this, I start with the value of k, and walk down that row of the triangle until I get to a value for which M(k,q) is greater than or equal to n. In doing so I will calculate (leveraging caching) k * (q-k) values in the triangle (assuming that this is the first run of solve so we don't have previously cached values. Since we know q is in the family of n^(1/k) we can say that this stage of the calculation takes O(k*n^(1/k)) time. The second part of the function involves generating the solution tree for the answer. To do this, I recursively walk the tree, generating the left and right hand sides as I go. This means that the generation will take linear time with respect to the number of nodes in the solution tree. This number is about 2*n meaning that the tree generation happens in O(n). Since the function is a composition of these two times, and O(n) clearly grows faster than O(k*n^(1/k)) the solve function should be in the family of O(n). -oppose Since this function is decided by caculating the solution for each claim, it too will happen in O(n) time, where n is the number of rungs for the largest ladder in the list of claims. -propose Again, this function relies on solve to compute the answers to each claimed instance. This means that it will take O(n) time where n is the number of rungs for the largest claimed ladder. Note that this could be implemented slightly more quickly by just walking pascals triangle (this would take O(k*n^(1/k)) time as shown above), but using the solve method seemed slightly cleaner to code. -provide This is done in constant time since the HSR playground has a single instance in each instance set. While I did run my avatar in the 100,000 rung tournament, it had some unfortunate memory issues that caused it to run out of memory on very large values of k. While it was computing the correct answer if given enough stack size, this clearly wasn't an optimal solution. The easy fix to this was to cap k at log(n) before starting to compute my solution. This drastically reduced the amount of recursion that my avatar had to do in order to generate solutions, leaving me with an avatar that computes 100,000 rung claims in ~20ms. This is possible because my solve function runs linearly with respect to the number of rungs in the HSR instance. I have tested on values up through n = 1,000,000 beyond this then I start running into stack overflow issues simply because the size of the solution is so large that it recures beyond the size of the stack. I expect that there's a way to compute these without recursion which would avoid this problem, but there's probably tradeoffs with performance and readability of code. Also assuming that a ladder's rungs are about a foot apart, a 1,000,000 rung ladder would go out to the orbit height of the international space station, so there's not much point tackling that problem right now :)