Exercise 3: Responding to "They're Mathematically the Same, Pick the Faster One" — Possible Solution ==================================================================== WHAT'S CORRECT ABOUT THE STATEMENT ------------------------------ It's true that the two formulas are algebraically identical in exact arithmetic, and it's true that the naive one-pass formula only requires a single scan over the data (accumulating sum and sum-of-squares together), while the two-pass formula requires computing the mean first and then scanning the data again to compute deviations - a genuine, real performance difference in favor of the one-pass approach. WHAT'S WRONG WITH THE CONCLUSION ------------------------------ "Mathematically the same" only holds in exact arithmetic - it does not carry over to floating-point arithmetic, which is what any real program actually uses. This chapter verified directly that the two formulas, run on identical real data, can produce wildly different results: the two-pass formula matched a high-precision reference to about 7*10^-17 relative error, while the naive formula returned -0.0625, a mathematically impossible negative variance, on the exact same input. Choosing "whichever is faster" while treating the two as interchangeable ignores that only one of them is actually reliable once real floating-point numbers and real data are involved - they're speed/reliability tradeoffs, not two equally valid options that differ only in performance. WHY THIS MATTERS SPECIFICALLY BECAUSE THE FAILURE IS DATA-DEPENDENT ------------------------------ The naive formula isn't unreliable for every dataset - this chapter verified it can be accurate for data centered near zero, and only degrades as the data's own offset grows large relative to its spread. This makes the risk worse in practice, not better: code using the naive formula might work correctly for a long time in testing and normal operation, then silently produce wrong or even impossible results the moment it encounters real-world data with a large baseline offset (e.g. large sensor readings, timestamps, or financial totals) - exactly the kind of bug that's hardest to catch before it reaches production. A BETTER RECOMMENDATION ------------------------------ If performance genuinely matters, the right response isn't "use the unstable one-pass formula" but "use a numerically stable one-pass algorithm" - stable single-pass variance algorithms exist (such as Welford's algorithm, which updates a running mean and variance incrementally without ever computing a large sum of squares) and get both the speed benefit and the reliability the naive sum-of-squares formula lacks. WHY THIS WORKS AS AN ANSWER ------------------------------ The response acknowledges what's genuinely true in the junior developer's reasoning (the algebraic equivalence and the real speed difference) rather than dismissing it outright, identifies the specific gap (exact-arithmetic equivalence does not imply floating-point equivalence) using this chapter's own verified result, and offers a concrete alternative rather than simply arguing the two-pass formula must always be used instead.