Why can repeated rounding make a result drift from the original value?

Because rounding changes the value you carry into the next step. The rounded value is close to the original, but it is no longer the same; later operations work on that altered value. Those differences can accumulate, or an operation can make them more noticeable.

For a simple example, suppose you need to add one third three times. If you round one third to two decimal places first, each term becomes 0.33. Then 0.33 + 0.33 + 0.33 = 0.99. If you keep the exact fraction, 1/3 + 1/3 + 1/3 = 1, and rounding at the end still gives 1. The gap is 0.01 in this example.

The key distinction is not that rounding is inherently wrong. It is that rounding early discards information that later steps might need.

It can matter in computer calculations too, although the details depend on the number format and operations. In JavaScript, numbers use 64-bit floating-point representation. MDN describes a case where adding 0.1 to 1e20 loses that small contribution in the intermediate result; subtracting 1e20 afterward produces 0 rather than 0.1. The example illustrates how information lost in an intermediate step can affect a later result. [S1]

That source is a JavaScript-specific example, not proof that every language, number type, or rounding rule behaves identically. It also notes that values such as 0.1 and 0.2 already have inexact binary representations. So keeping more intermediate precision can help, but it does not make every input exact or remove all possible numerical error. [S1]

Keep the original or highest-precision values available through the calculation, and round when you present the final result or when a clearly defined step requires a rounded value. For example, if a calculation uses three equal shares of 1, keep each share as 1/3 (or carry sufficient decimal places) while summing; do not replace each share with 0.33 and then treat those rounded numbers as exact.

A practical workflow is:

1. Write down the inputs and the precision they contain.
2. Decide whether the task explicitly requires rounding at an intermediate step.
3. Otherwise, calculate using unrounded values or a suitable exact representation.
4. Round the final result to the required number of decimal places.
5. If results still differ, check the input representations, operation order, and rounding rule.

For money or other calculations governed by a particular rule, follow the rule that applies to that task rather than assuming a universal rounding convention.

Copy this example and change the number of repeated terms if useful:

Round first: 1/3 → 0.33; 0.33 + 0.33 + 0.33 = 0.99

Round at the end: 1/3 + 1/3 + 1/3 = 1; rounded to 2 decimal places = 1.00

The comparison assumes ordinary decimal rounding to two places for the first line and exact fractions for the second. It demonstrates this particular calculation; it does not establish which rounding rule a different application should use. For computer arithmetic, the chosen representation and operations also matter. The general habit is to avoid throwing away precision earlier than the task requires.