Rounding calculator
Put 2.5 in at zero places and the rows split three ways: 3 by standard rounding and by ceiling, 2 by floor, by truncation and by banker’s. Change it to 2.4 and every row except ceiling agrees on 2. That is the whole shape of the problem — rounding is uncontroversial until the value sits exactly on the boundary, and then the convention you picked is the entire answer.
This rounds a single value by every method at once, so you can see which one your answer depends on. Standard rounding sends 2.5 to 3. Banker’s rounding sends it to 2, the nearest even number, which is what most financial software and the IEEE 754 standard your processor already implements actually do. Ceiling always goes up, floor always goes down, and truncation just drops the digits — which is not the same as floor once the number is negative.
How to use it
Rounding looks like one operation and is at least five, and they are indistinguishable until a value lands exactly on a boundary. That is why a total can be defensible, reproducible and still disagree with the system next to it by a few cents.
Banker’s rounding is a bias fix, not a quirk
Always sending a half upward is not neutral. Across many values it adds a systematic drift, because the halves only ever move in one direction and nothing ever pulls the other way. Over a million transactions that drift is real money and it is always in the same direction. Round-half-to-even removes it by sending 2.5 to 2 and 3.5 to 4, so the halves split evenly between up and down and cancel in aggregate. It is the default rounding mode in IEEE 754, which means your processor is already doing it inside every floating-point operation, and it is what most accounting packages apply to a line total. If a figure you produce has to reconcile against one of those, the halves are the only values that can disagree, and this is the row to check them against.
Floor and truncate part company below zero
For a positive number, dropping the decimals and rounding down are the same act, which is why the distinction goes unnoticed for years. Below zero they diverge: floor(−2.5) is −3, because −3 is genuinely the lower number, while truncating gives −2, because it simply deletes the digits and leaves the sign alone. Most programming languages give you both under names that do not warn you which you have picked. A quantity that must never be exceeded wants floor; a display that must never gain a digit wants truncation; and a signed value passing through the wrong one is a class of bug that only appears in the negative half of your data.
Round once, from the original
The other reliable way to get a wrong answer is to round twice. Take 2.44: to one decimal it is 2.4, and rounding that to zero gives 2, which is also what you get going straight there. Now take 2.45. To one decimal it is 2.5, and to zero from there it is 3 — but 2.45 rounded directly to zero places is 2. The intermediate value carried the number across a boundary it never actually crossed. This is exactly how a spreadsheet total comes to disagree with the sum of the rows displayed above it: the display rounds, the sum does not, and somewhere a person retypes the displayed figures. Always round once, from the value you started with, to the precision you actually need.
The nearest multiple is the same trick, scaled
Rounding to the nearest 5, 10 or 0.25 is division, rounding, and multiplication back: 47 to the nearest 5 is round(47 ÷ 5) × 5 = 45. The multiple field does it for you because the arithmetic is easy to get subtly wrong by hand when the multiple is not a whole number. Quarter-hour timesheets, quarter-inch measurements and prices ending in .95 are all this operation, and none of them is a decimal-places question at all.
What people use it for
- Checking whether a figure survives banker’s rounding before it goes into an invoice
- Working out why a spreadsheet total disagrees with the sum of its displayed rows
- Deciding between floor and truncation for a value that can go negative
- Rounding a timesheet to the nearest quarter hour
- Rounding a price to the nearest 5 or 10
- Settling what a number rounds to when it sits exactly on a half
Questions
Three by standard rounding, two by banker’s. Both are correct, and which one is right depends entirely on what the number feeds into. If it will be summed with hundreds of others, banker’s is the one that will not drift.
Halves go to the nearest even number rather than always upward, so 2.5 becomes 2 and 3.5 becomes 4. Rounding every half up biases a large set of values upward; sending them alternately up and down cancels that out. It is the IEEE 754 default, so your processor already works this way, and most financial systems follow it for the same reason.
Nothing at all for positive numbers, which is why the distinction is easy to miss. For negatives, floor goes down — floor(−2.5) is −3 — while truncation moves toward zero and gives −2. Pick floor when the value must never be exceeded and truncation when digits are simply being dropped.
Use the multiple field. It divides by your multiple, rounds, and multiplies back, so 47 to the nearest 5 is 45 and 7.4 to the nearest 0.25 is 7.5. It is a separate row from the decimal-places answer rather than a replacement for it.
Almost always one of two things. Either the cells display a rounded value while the sum uses the full one, so the visible rows genuinely do not add to the visible total; or a value was rounded twice, once for display and again by hand. Round once, from the original.
No — that is a different question and it has its own page. Decimal places count from the point; significant figures count from the first non-zero digit, so 0.0045678 to two decimal places is 0.00 and to two significant figures is 0.0046.
Because 1.005 is not exactly 1.005 in binary floating point; the stored value is a hair below it, and rounding is honest about the number that is actually there. Every language with binary floats does this. It is a representation limit, not a rounding bug.