Round 2.675 to two decimal places by hand and the answer is 2.68 — the digit in the third place is 5, and the standard rule rounds a 5 up. Ask many calculators or spreadsheets to do the identical rounding and a surprising number of them return 2.67 instead. Neither one is malfunctioning. Something genuinely interesting is happening underneath, and it is worth understanding rather than dismissing as “just a rounding bug.”
The number that cannot be stored exactly
Computers store decimal numbers in binary floating-point, and binary floating-point cannot represent every decimal fraction exactly — in the same way that 1/3 cannot be written exactly as a finite decimal. 2.675 is one of the numbers that falls into this gap. The actual value stored is not 2.675 — it is something fractionally below it, roughly 2.674999999999999822…. That value is genuinely, if almost imperceptibly, below the halfway point between 2.67 and 2.68. Standard rounding rules correctly round it down, to 2.67 — and the software is not wrong, it is rounding the number it actually has stored, which is not quite the number you typed.
Why this matters more than it sounds like it should
A page that shows 2.67 to someone who worked the same calculation out by hand and got 2.68 looks broken, and reasonably so — from their perspective, they typed 2.675 and got a different-looking answer with no explanation. The gap between “the number you typed” and “the number stored” is invisible unless something explicitly surfaces it. The rounding calculator handles this by rounding the digit string you actually typed — 2.675, read as text — rather than the binary approximation that typing it produces internally, and it flags the cases where the two methods would have disagreed, rather than silently picking one and hoping nobody notices.
A related trap: precision that looks fake
The opposite-looking problem shows up too. Ask for four decimal places of precision on a result that happens to be exactly 3.5, and a naive display shows “3.5” — technically correct, but not what was asked for. The calculator is built to show exactly the requested precision, so a four-place request against 3.5 displays as 3.5000, and 2.68 does not quietly grow trailing zeros into 2.6800000000 from leftover binary noise either. Both directions — under-displaying and over-displaying — are failures of the same underlying issue: floating-point values carry more or less apparent precision than the number a person actually intended.
The five rounding rules, and where they diverge
Beyond the halfway-point issue, “round” itself is not one rule. Half up, half to even (banker’s rounding), ceiling, floor, and truncate all agree everywhere except exactly at a halfway value — and ceiling and floor specifically diverge from magnitude-based rounding on negative numbers, since ceiling always rounds toward positive infinity and floor always rounds toward negative infinity, regardless of which direction that happens to be “up” or “down” in everyday terms for a negative number.
A related but different issue: significant figures
Floating-point precision, discussed above, is about a number being stored slightly differently from how it was typed. A separate and equally common source of “why did this round differently than I expected” is significant-figure ambiguity — covered in full in scientific notation and significant figures — where a bare number like 1500 does not even specify how many of its digits are meant to be precise in the first place. The two issues compound in practice: a number can carry genuine significant-figure ambiguity and be stored with floating-point imprecision at the same time, which is one reason financial and scientific software increasingly stores exact figures — dollars and cents as integers of cents, for instance — specifically to sidestep the floating-point half of the problem entirely.
Why this rarely matters for everyday numbers but matters a lot for money
Floating-point imprecision is present in essentially every decimal number a computer stores, but it usually stays invisible because it is far smaller than the precision anyone is actually using — a tiny error many decimal places past where a result is displayed simply never surfaces. It becomes visible specifically at rounding boundaries, where a value sits almost exactly halfway between two displayed results, which is disproportionately likely to happen with money, since currency amounts are frequently entered as clean decimals (like 2.675) that do not happen to have exact binary representations. This is the deeper reason serious financial software avoids ordinary floating-point arithmetic for currency entirely, instead storing amounts as whole numbers of the smallest unit (cents, for a dollar-based currency) specifically to sidestep this class of error from the start.
How to use this
- If a calculated result looks off by exactly one unit in the last decimal place compared to hand arithmetic, suspect a halfway-rounding case before suspecting a bug.
- When precision genuinely matters — financial figures, published measurements — round the digit string a human typed, not the binary value it became internally.
- Different rounding rules exist because different situations call for different ones — banker’s rounding exists specifically to avoid systematic bias when rounding large volumes of halfway values in one direction.
