e^x无穷求和结果异常：无阶乘实现极端值计算失效排查

Great call using the iterative ratio method to compute e^x—this is a clever way to avoid the overhead and potential overflow of calculating factorials directly, and it works beautifully for small x values. But as you've noticed, it falls apart hard for extreme negative inputs like x=-50, spitting out a nonsensical negative result instead of the expected ~1.9287498e-22. Let's break down why this happens and how to fix it.

Why the Original Method Fails for Large Negative x #

Your approach relies on the Taylor series expansion of e^x:

e^x = 1 + x + x²/2! + x³/3! + x⁴/4! + ...

Instead of computing factorials, you generate each term by multiplying the previous term by x/n (since term_n = term_{n-1} * x/n). For small x, this is efficient and stable, but for large negative x, two big problems pop up:

• Alternating large terms: The terms swing between large positive and negative values (e.g., x=-50 gives terms like 1, -50, 1250, -20833.333...). As you add these up, floating-point precision can't keep up—when you subtract a huge value from a huge sum, you lose significant digits, and eventually, the small later terms (which should converge to the tiny true value) get completely swallowed by the error.
• Sign cancellation chaos: The alternating signs mean that small rounding errors in the large early terms get amplified as you keep adding, leading to the final result being wildly off (like that negative number you saw).

The Fix: Use Symmetry of the Exponential Function #

The exponential function has a key property that saves us here: e^x = 1 / e^{-x}.

When x is a large negative number, -x is a large positive number. Calculating e^{-x} with your iterative method is stable because all terms are positive and monotonically decreasing (each term is the previous one multiplied by a positive value: -x/n). There's no sign cancellation to mess up precision, and the sum converges cleanly to the correct large value. Then you just take the reciprocal to get e^x, which will be the tiny positive number you expect.

Implementation Example (C-like Pseudocode) #

double calculate_exp(double x) {
    // Handle negative x by computing reciprocal of exp(-x)
    if (x < 0.0) {
        return 1.0 / calculate_exp(-x);
    }
    
    double sum = 1.0;
    double current_term = 1.0;
    int n = 1;
    
    // Stop when term is negligible relative to sum (adjust precision as needed)
    while (fabs(current_term) > 1e-16) {
        current_term *= x / n;
        sum += current_term;
        n++;
    }
    
    return sum;
}

Testing this with x=-50: first we compute e^50 (which is ~5.1847055e21), take its reciprocal, and we get exactly the ~1.9287498e-22 you're expecting—no more negative garbage.

Bonus: Handling Extremely Large Positive x #

If you also need to handle huge positive x (like x=1000), the iterative method might hit floating-point overflow as terms grow too big. For those cases, you can split x into a sum of k * ln(10) (a multiple of the natural log of 10) and a remainder r where |r| < ln(10). Then:
e^x = e^{k*ln(10)} * e^r = 10^k * e^r
Calculating 10^k as a power of 10 (easy with exponentiation) and e^r with the iterative method avoids overflow. But for most practical use cases, the symmetry fix above will cover your needs.

内容的提问来源于stack exchange，提问作者Megadardery