Seven ways to round the same number
Most of the time rounding is unambiguous: 23.7 rounds down to 23 and 23.2 rounds up to 24 no matter which method is used, because neither sits exactly on the boundary. The methods only disagree when a number falls exactly halfway, like 2.5 or -2.5, and even then the four "directed" methods don't need a tie rule at all: floor (round down / toward -∞) always takes the lower integer, ceiling (round up / toward +∞) always takes the higher one, and truncate just chops the decimal part off, so 2.5 becomes 2 and -2.5 becomes -2.
Ties only come up for the "round to nearest" methods, and Wikipedia's rounding article documents four distinct tie-breaking conventions: half up sends every tie toward +∞ (2.5 → 3, but -2.5 → -2, since -2 is the greater of the two candidates: "toward +∞" always means picking the larger value, whichever sign it has); half down sends every tie toward -∞ (2.5 → 2, -2.5 → -3); half away from zero treats both signs the same and always rounds the tie outward (2.5 → 3, -2.5 → -3); and half to even, commonly called banker's rounding, breaks the tie toward whichever candidate integer is even (2.5 → 2, 3.5 → 4, -2.5 → -2). Pick the wrong one for the context and a batch of numbers rounds with a small but real bias in one direction.
"Half up" doesn't mean the same thing everywhere
This is a well-documented source of calculator disagreements, not user error. Wikipedia's rounding article notes that "some programming languages (such as Java and Python) use 'half up' to refer to round half away from zero rather than round half toward positive infinity," which is the textbook definition. The two conventions only diverge on negative numbers: -2.5 becomes -2 under the toward-positive-infinity definition, but -3 under the away-from-zero definition. If a spreadsheet, a calculator, and a piece of code all round the same negative half-value differently, this is almost always why. This calculator keeps the two options separate ("Half up" and "Half away from zero") instead of picking one and hiding the choice.
Banker's rounding gets its name from accounting, where always rounding 0.5 the same direction (e.g. always up) systematically inflates a large batch of sums; alternating between round-down and round-up ties largely cancels that out. It's also the default IEEE 754 rounding mode for binary floating-point math and the recommended default for decimal floating-point, which is why it shows up as the built-in behavior of Python's round() function and several spreadsheet and database engines, sometimes surprising people who expect classic half-up rounding instead.
Decimal places vs. significant figures
Rounding to a number of decimal places counts digits after the decimal point, full stop. 3.14159 to 2 decimal places is 3.14, and 0.00042 to 2 decimal places is 0.00, because both of its meaningful digits fall in the fourth and fifth decimal place. Rounding to significant figures instead counts meaningful digits starting from the first nonzero digit, ignoring leading zeros: 0.00042 to 2 significant figures is 0.00042 unchanged (it already has exactly 2), while 0.0034567 to 2 significant figures is 0.0035. The two modes agree for numbers already close to 1, and diverge sharply for very small or very large ones.
Significant-figures rounding can also carry a value across a power of ten: 995 rounded to 2 significant figures is 1000, not 990. That is a tie, not a lean toward one side: 995 sits exactly halfway between the two candidate 2-significant-figure values, 990 and 1000, so which one it lands on depends on the tie-breaking method, and the default here (half up, ties toward +∞) sends it to 1000. Written as plain digits, 1000 looks like it has 4 significant figures even though only 2 are meaningful. That is exactly the ambiguity scientific notation exists to remove, which is why this calculator also shows a 1.0 × 10³-style reading whenever significant-figures mode is selected.
Why 1.005 is the classic floating-point trap
A number like 1.005 has no exact representation in IEEE 754 binary floating point, the format underlying nearly all calculators, spreadsheets, and programming languages: the closest representable double-precision value is actually about 1.00499999999999989, a hair below 1.005. Rounding that stored value to 2 decimal places with ordinary half-up logic lands on 1.00, not the 1.01 the original decimal digits called for. That is a real, reproducible quirk of binary arithmetic, not a bug specific to any one tool. This calculator sidesteps it entirely by parsing the digits typed in directly and rounding them as exact decimal values, so a case like 1.005 → 1.01 comes out the way the digits themselves say, with no floating-point conversion step in between.