Problem Analysis
A continued fraction represents a number as a nested expression a0 + 1/(a1 + 1/(a2 + ...)), where the integers a_k are the partial quotients. If you truncate the expansion after k levels you get a rational number called the k-th convergent; these are provably the best rational approximations to the underlying real number for their denominator size. For the constant e the partial quotients follow a clean rule: [2; 1, 2, 1, 1, 4, 1, 1, 6, ...], where every third quotient is an even number 2k and all the others are 1. The task asks for the numerator of the 100th continued fraction convergent of e, then the sum of that numerator's decimal digits.
The key observation is that I never need to evaluate the nested fraction by hand. The numerators h(k) and denominators of successive convergents obey the standard three-term convergent recurrence h(k) = a(k)*h(k-1) + h(k-2), seeded with h(0) = 1 and h(1) = a(1). This turns an awkward nested division into a plain linear iteration. The one complication is magnitude: the numerator grows roughly like e^n, so by n = 100 it has about 40 decimal digits - already past the range of a 64-bit integer - and by n = 10000 it spans thousands of digits. Since each multiply-add touches all O(n) digits of the running value, the whole computation costs O(n^2) digit-operations: quadratic, but easily fast enough.
Solution Approach
Three-Term Convergent Recurrence (Python and C)
Both files compute the same quantity via the same convergent recurrence; they differ only in how they manage the large numerator. Each starts with a small helper, e_denominator(n), that encodes the partial-quotient pattern directly: it returns 2 for n == 1, 2*(n/3) when 3 divides n, and 1 otherwise. I chose to express the rule as a tiny function rather than a precomputed table, because the function is trivially correct for any n and generalises immediately without resizing anything.
The C solution iterates the recurrence directly. It seeds h_prev2 = 1 (the artificial h(0) that makes the first multiply-add come out right) and h_prev1 = 2 (which is a(1)). For each k from 2 to n it computes h_curr = a(k)*h_prev1 + h_prev2 and rotates the three buffers so only the two most recent numerators survive. After the loop, h_prev1 is the numerator of the n-th convergent, and a digit-sum pass produces the answer.
The Python solution expresses the same mathematics recursively. nth_convergent_of_e descends to depth n and then unwinds, repeatedly forming a + 1/sub-result using fractions.Fraction for exact rational arithmetic. This is a literal transcription of the definition of a continued fraction, so it is very easy to verify by inspection. Its cost is that it carries both numerator and denominator through every level and recurses to depth n - which is why it raises sys.setrecursionlimit - making it slower than the pure-numerator iteration at large n. The digit sum falls out of sum_digits, a repeated mod-10 / divide-10 loop.
The C version has no built-in big integers, so it supplies its own. It stores a number as an array of unsigned long long limbs in base 10^9 (the BigInt type). The workhorse is bigint_mul_add(dst, a, scalar, b), which computes a*scalar + b in a single pass: at each limb position it forms av*scalar + bv + carry, stores val % BASE, and propagates val / BASE. I deliberately picked base 10^9 for two reasons. First, the product of a limb (under 10^9) and a small scalar (at most about 6667 at n = 10000), plus a carry, stays comfortably within 64 bits, so no overflow can occur. Second, because the base is a power of ten, each limb is itself a block of decimal digits, so the final digit sum is a free byproduct rather than requiring a base conversion.