## Chapter 14: Numerical Methods (Practical) — when “almost correct” is the only possible correct Here’s something that surprises people: In many programs, you don’t get the exact answer. You get a close answer. And that’s not a bug. That’s how computers work with real numbers. ### The classic confusion: why 0.1 + 0.2 is not exactly 0.3 You may have seen this in code: ```text 0.1 + 0.2 = 0.30000000000000004 ``` Students think: “My language is broken.” No. The math is fine. The storage is limited. Computers store decimal-like numbers in **binary fractions** (floating-point). And many simple decimals (like 0.1) do not have a clean ending in binary. So the computer stores the nearest possible value. Then when you add, the tiny error also adds. Numerical methods is basically the skill of: - working with approximations safely - controlling errors - still getting reliable results ### A simple truth: real life is continuous, computer is discrete Real world values: - time - temperature - speed - audio signal - image intensity These can change smoothly (continuous). But a computer stores them as: - limited bits - fixed precision - rounded values So numerical work is always “best effort inside limits”. ### Two words you must respect: precision and error - **precision**: how many digits (or bits) you can keep - **error**: how far your stored value is from the real value Even if error is tiny, it can become big if you do bad operations again and again. #### Basic: rounding is normal Suppose you store money as float: ```text 0.1 + 0.1 + 0.1 ``` You expect 0.3 exactly. But floats can produce small noise. That’s why in finance systems, people often store: - money in **cents** as integer Example: - ₹10.25 → 1025 paise Now addition is exact. This is numerical thinking: choose representation that avoids error. #### Common mistake: comparing floats with == Beginners do: ```text if (a == b) ... ``` With floats, a and b can be “almost same” but not exactly same. Better habit: Check if they are close: ```text abs(a - b) < tiny_value ``` This “tiny_value” is called tolerance (epsilon). This one habit saves a lot of bugs in: - physics simulations - graphics - ML training #### Simple reason: why subtraction can lose information This feels weird, but it happens. If you subtract two very close big numbers, you can lose precision. Example idea: - x = 1000000000.123456 - y = 1000000000.123455 The true difference is 0.000001. But if your float cannot store all digits correctly, the difference can become noisy. This is called “catastrophic cancellation”. Subtraction of close numbers can be unstable. Sometimes you need to rewrite formulas to be stable. #### Practical: repeated addition creates drift (simulation bug) In games or physics code, you update position like: ```text position = position + velocity * dt ``` You do this thousands of times per second. Each step has tiny rounding. After many steps, the object can drift a little bit. So pros do things like: - occasionally re-normalize values - use better integration methods (we won’t go deep today) - store some values in double precision This is numerical methods in real life: “tiny error × many steps = visible error”. #### Practical: finding roots (binary search style thinking) Many problems are like: “Find x such that f(x) = 0.” Example: - find square root of 2 - solve equation in physics Computers often use iterative methods: - guess a value - improve the guess - stop when close enough Even square root in many systems is computed using iterations inside CPU. So “numerical method” can be as simple as: “Keep improving until error is small.” #### Extra tip: when to stop (convergence) When you iterate, you need a stopping rule: - stop after K steps - or stop when change becomes very small - or stop when error is below tolerance If you stop too early, answer is bad. If you stop too late, you waste time. So numerical methods is always balancing: - accuracy - performance That’s the engineer mindset. ```