How do math.floor, math.ceil and math.trunc differ on a value like -2.5?

## Four operations, four directions Python offers four ways to turn a value with a fractional part into a whole number, and they differ only in which way they go: | call | direction | on 2.5 | on -2.5 | |---|---|---|---| | `math.floor(x)` | toward negative infinity | 2 | -3 | | `math.ceil(x)` | toward positive infinity | 3 | -2 | | `math.trunc(x)` | toward zero | 2 | -2 | | `round(x)` | to the nearest, ties to even | 2 | -2 | On positive input, `floor` and `trunc` are indistinguishable — which is exactly why a bug written with the wrong one survives every test that uses positive numbers, and fires the first time a negative value arrives. Interviewers use `-2.5` for the same reason. ```python import math for x in (2.5, -2.5): print(x, round(x), math.floor(x), math.ceil(x), math.trunc(x)) # 2.5 2 2 3 2 # -2.5 -2 -3 -2 -2 ``` ## Return types In Python 3 all three `math` functions return an `int`, not a float. That is a change from Python 2, where `math.floor(2.5)` gave `2.0`. It matters when the result is used as an index or a count, and it means `math.floor` is a perfectly good way to get an integer floor without any extra conversion. `round()` is the odd one out on typing: with no second argument it returns an `int`, but with `ndigits` it returns the argument's own type. ## Symmetry and asymmetry `floor` and `ceil` are mirror images about zero — `math.ceil(x)` equals `-math.floor(-x)` — so they behave *consistently* on negatives, always stepping the same absolute direction on the number line. `trunc` is the one that changes behaviour with the sign: it steps down for positives and up for negatives, because 'toward zero' is a direction that depends on which side of zero you are on. That asymmetry is what makes truncation a poor choice for anything that must partition a number line evenly, such as bucketing timestamps or coordinates that can go negative. ## They are protocols, not float special cases Each function delegates to a dunder on the argument's type: `math.floor` calls `__floor__`, `math.ceil` calls `__ceil__`, `math.trunc` calls `__trunc__`, and the builtin `round()` calls `__round__`. A type of your own opts in by defining them: ```python import math class Cents: def __init__(self, value): self.value = value def __floor__(self): return Cents(math.floor(self.value)) def __trunc__(self): return int(self.value) def __round__(self, ndigits=None): return Cents(round(self.value, ndigits)) c = Cents(-2.5) print(math.floor(c).value, math.trunc(c), round(c).value) ``` If a type defines only some of them, the others raise `TypeError`. Note also that as of Python 3.12 the `int()` builtin no longer falls back to `__trunc__`; a class that wants to be convertible with `int()` must define `__int__`, and `__index__` is what makes it usable in slicing and as a sequence index. ## Choosing the right one * Bucketing a continuous value into fixed-width bins, where the bins must be uniform across zero — `math.floor`. * Sizing a container to hold everything, such as the number of pages needed for a row count — `math.ceil`. * Dropping a fractional part while preserving the sign's magnitude direction, for instance to display a signed whole-unit part — `math.trunc`. * Reporting the nearest value to a human — `round`. A useful self-check when reviewing code: if a call to `math.trunc` or an implicit truncation appears anywhere the input can be negative, ask whether the author actually meant `math.floor`. That mix-up is one of the most common quiet defects in bucketing and offset arithmetic, and it never shows up in a test suite whose fixtures are all positive.