Rounding 在算法设计里是个特别有意思的词——它不单指语言手册里的四舍五入函数，更是一种把“连续”变“离散”、把“浮点”变“整数”的思维。很多看起来麻烦的问题，一旦用对舍入方式，代码量直接砍半，正确率反而更高。这篇文章想分享我在工程和算法题里反复用到的几类舍入技巧：从最基础的取整语义差异，到坐标离散化、数据分桶，再到进阶的线性松弛舍入思路，最后附上我踩过的一些精度坑和排查经验。不管你是打比赛、写工具脚本，还是在业务系统里跟浮点数打交道，这份总结应该都能帮你少走点弯路。

我最初对 rounding 的理解很肤浅，觉得就是round()一下的事。后来在调试一个几何计算小工具时，被精度问题折磨了一整晚：点明明在线上，判断程序却输出“在线外”；区间统计时明明该落在第三个桶，结果落到第二个。从那时起我才意识到，取整是一个需要被认真对待的算法设计决策，而不是随手调个函数。

1. 先分清取整语义：比想当然更早踩坑

1.1 四种取整方式的细节差异

大多数人对取整的认知停留在“四舍五入”，但放到程序里，floor、ceil、trunc、round 四个函数的行为完全不同。尤其当输入是负数时，出错概率极高。

拿2.3、-2.3、2.7、-2.7四个数做个对照：

很多第一次接触 floor 的人会觉得floor(-2.3)应该是-2，因为它“舍掉了小数部分”。但 floor 的数学定义是“不大于 x 的最大整数”，所以结果必然是-3。trunc 才是那个直接丢掉小数部分、朝零取整的函数。这个差异不是概念游戏，而是我后来排查分桶错位问题时最重要的线索。

C++ 里这几个函数都在<cmath>里，重载了double和float版本；Python 的int()实际上做的是 trunc，而math.floor才是正儿八经的向下取整。写代码时不能想当然认为“转整数就是取整”。

1.2 浮点误差，以及 epsilon 为什么必备

哪怕取整函数本身没问题，浮点数的表示误差也会让结果变得不可预测。经典的例子是0.1 + 0.2在二进制浮点里并不等于0.3，而是一个接近0.30000000000000004的数。如果你直接判断0.1 + 0.2 == 0.3，得到 false，这不是语言 bug，而是任何二进制浮点都绕不开的误差。

因此算法题里比较浮点数时，几乎不会写a == b，而是写abs(a - b) < eps。这个 eps 的取值有讲究：取太大，会把本来不同的数误判成相等；取太小，又可能因为累积误差导致本应相等的数被判不等。我常用的经验是：先估算运算过程中数值的量级，再让 eps 比可能的最大误差高一个数量级。

举个例子，坐标范围在1e6以内、只做几次加减乘除时，误差通常在1e-9量级；但如果做乘方、开方或者多轮迭代，误差会膨胀到1e-6甚至更大。这时候 eps 取1e-9就会出问题。我的习惯是写一个带sgn的辅助函数：

const double EPS = 1e-9; int sgn(double x) { if (fabs(x) < EPS) return 0; return x < 0 ? -1 : 1; }

所有需要判断大小关系的地方，都用sgn(a - b)而不是a < b。

1.3 语言差异中的隐藏坑

取整语义在不同语言里经常反向操作，这一点真是吃过大亏。C++ 里int(x)是向零截断；Java 的Math.round()是“四舍五入”，但它在负数上的处理很反直觉：Math.round(-2.5)返回-2，而不是数学意义下的“先算 -2.5 再进位”的-3。原因在于 Java 的实现是floor(x + 0.5)：-2.5 + 0.5 = -2.0，所以结果是-2。Python 的round()更特殊，它默认使用“银行家舍入”——刚好遇到0.5时取到最近的偶数。比如round(2.5)是2，round(3.5)是4，跟很多人脑子里的四舍五入完全不一样。

所以跨语言移植代码时，取整逻辑必须重写并自测，不能直接复制粘贴。一个建议是：把“取整方向”和“取整函数”封装成统一命名的工具函数，比如floorDiv、ceilDiv、roundHalfUp，在函数注释里写清楚语义，避免团队协作时互相踩坑。

2. 离散化与几何判定：把浮点问题变成整数问题

2.1 坐标离散化：本质是区间编号

离散化（坐标压缩）是算法题和工程里极常用的手段：把一组可能很大的连续坐标，映射成从 0 开始连续排列的整数。很多人只把它当成“排序+去重”的套路，但在我看来，它本质上是把“浮点/大整数比较”舍入成“数组下标索引”的过程。

常规写法：

vector<double> coords; // 所有可能出现的坐标 sort(coords.begin(), coords.end()); coords.erase(unique(coords.begin(), coords.end()), coords.end()); int id = lower_bound(coords.begin(), coords.end(), x) - coords.begin();

经过这一步，原本需要二分查找比较的浮点数，变成了 O(1) 的数组下标。对于大规模范围查询、扫描线、线段树这类场景，收益立竿见影。但要注意：这个lower_bound返回的是“第一个不小于 x 的位置”，等价于ceil。如果你希望把 x 归入“小于等于它的最大坐标桶”，就需要用upper_bound再减一，语义上等价于floor。离散化看似简单，取整方向却直接决定边界是否算错。

2.2 叉积与三点共线：精度比功能更容易错

计算几何里最基础的判断就是“点在直线哪一侧”，实现用的是向量叉积。假设直线过A、B两点，要判断点P在直线的哪一侧，计算：

cross = (B.x - A.x) * (P.y - A.y) - (B.y - A.y) * (P.x - A.x)

如果cross > 0，点在一侧；cross < 0，点在另一侧；cross == 0，点在直线上。问题就出在这个== 0上。浮点运算后，理论上共线的三点算出的 cross 可能是一个极小的非零值，比如1e-10，直接判断cross == 0必然失守。

稳妥的做法是用前面写的sgn函数：

int pos = sgn(cross); if (pos == 0) { // 点在直线上 } else if (pos > 0) { // 一侧 } else { // 另一侧 }

同时，如果题目给的坐标全是整数，我强烈建议用long long保存坐标并直接计算整数叉积。整数运算是精确的，完全不需要 epsilon，只要注意乘积不要超过9e18。能用整数判定，就不引入浮点，这是计算几何里性价比最高的习惯。

2.3 一个完整的整数判定案例

举一个我后来经常套用的例子：判断点P是否在圆内。圆的圆心为O、半径为r，如果r是浮点，常规做法是算距离sqrt(dx*dx + dy*dy)再和r比较。但开方本身就有误差，更好的做法是直接比较距离平方和半径平方：

long long dx = P.x - O.x; long long dy = P.y - O.y; long long dist2 = dx * dx + dy * dy; long long r2 = r * r; if (dist2 < r2) { // 在圆内 } else if (dist2 == r2) { // 在圆上 } else { // 在圆外 }

如果半径是2.5这种小数，可以先把所有坐标同时乘2，把问题缩放成整数再比较。缩放时需要选好倍数，既要消掉小数部分，又不能溢出。这个“先放大、再判定、最后缩小”的思路，本质上就是在做 rounding 设计——把连续问题映射到离散整数域，换取精确和速度。

3. 分桶、哈希与近似计数：舍入的工程价值

3.1 连续值映射到桶号：一个负数就翻车

做监控统计时，经常要把连续指标分成若干区间，比如把接口延迟分成[0, 50)、[50, 100)、[100, 200)等桶。一个直观公式是：

bucket = (int)(value - minValue) / step

但这里有个大坑，(int)做的是截断，也就是 trunc。如果value - minValue是负数，比如-0.5，(int)会得到0，而floor会得到-1。对于区间划分来说，负的偏移量应该落在更小的桶里，不是 0 桶。我在一个延迟统计工具里就吃过这个亏：一批请求耗时略低于 minValue 时，全被塞到了最小桶，直方图前几个桶数值异常偏大。

正确写法：

int bucket = (int)floor((value - minValue) / step); if (bucket < 0) bucket = 0; // 下界保护 if (bucket >= bucketCount) bucket = bucketCount - 1; // 上界保护

或者更简单，先整体平移再做非负运算：

double shifted = value - minValue; int bucket = (int)(shifted / step); // 平移后 shifted >= 0 时截断等价于 floor

记住：只要范围可能跨零，就不要用默认的 int 截断。

3.2 近似基数估计里的舍入思想

搞数据结构和系统设计的同学应该听过 HyperLogLog，它用极小内存估计超大规模集合的基数。HLL 的核心操作里就有一个隐蔽的舍入思想：它不直接记录每个元素的精确哈希值，而是记录“哈希值二进制表示中从低位开始连续零的个数”。这个连续零的个数，实际上是把哈希值按区间[2^k, 2^{k+1})做了对数分桶。

为什么要这么舍入？因为记录精确哈希值需要 32 位甚至 64 位空间，而记录“k 的范围”只需要log2(k)位。这里的代价是牺牲一定精度，换来内存占用从线性变成对数级。HLL 之所以能在几千字节内存里统计上亿元素，靠的就是这一层对哈希值的“按数量级取整”。

我后来做流量去重统计时也借鉴了这个思路：把用户 ID 哈希后只保留前 k 位作为桶编号，后面的位数用于组内估算。事实是，在很多“不需要完全精确、只需要知道量级”的场景，这类对数取整产生的相对误差完全可接受，而内存节省非常客观。

3.3 用舍入换复杂度：量化与近似

除了统计场景，量化也是一种 rounding。图像处理里把连续灰度值量化成 256 级，音频采样把连续振幅量化成 16 位整数，都是通过舍入把连续数据变成固定位宽的离散数据。工程上很多“压缩”“索引加速”“布隆过滤器”等设计，底层都藏着某个形式的舍入。

做排行榜时，如果把每个用户的积分精确存成浮点数，按范围查询会非常吃力。我见过一个方案：把积分除以 100 向下取整作为“积分段”，再为每个段建一个倒排索引。查询“积分在 1000 到 1500 之间”的用户时，直接查 10 到 15 两个段的索引，再把边界段内的精确数据过滤一遍。这种粗粒度分桶让查询量降了一个数量级，而误差范围控制在 100 分以内，产品上完全说得过去。

允许的误差越大，能砍掉的数据结构和计算量往往也越大，这是工程里经常要做的 trade-off。

4. 从线性松弛到随机舍入：进阶的设计思路

4.1 连续解取整：资源分配和容量规划

很多算法问题会先求一个“连续最优解”，再把它变成整数可行解。最典型的就是资源分配：现有 T 个小时的处理时间，每个任务平均需要 2.5 小时，问最少需要几个并行处理单元才能按期完成。首先算出T / 2.5，如果结果是4.3，那显然需要 5 个单元——向上取整保证不会超时；如果问题是“最多能承载多少个任务”，那就要向下取整，否则会超载。

这类问题看似简单，但在实际算法题里经常藏在二分答案、贪心验证、背包变体中。取整方向一旦选反，结果就差一个单位，小则 WA，大则在生产环境直接资源估算错误。我总结的经验法则是：先明确约束是“必须满足下限”还是“不能超过上限”，下限用 ceil，上限用 floor。

4.2 随机舍入：把概率变成决策

在更进阶的组合优化里，有一类经典技术叫随机舍入（randomized rounding）。思路很简单：先解一个整数规划的实数松弛版本，得到每个变量在[0,1]间的取值，然后不直接粗暴地取 0 或 1，而是把这个实数当作一个概率去随机选择。

举个例子，假设某个任务做完要选 3 个服务节点，松弛解给节点 A 的取值是 0.7，那就以 0.7 的概率选它，以 0.3 的概率不选。为什么不做成“大于 0.5 就选”？因为松弛解往往存在系统性误差，固定阈值会累积偏差，而随机化可以让多个决策互相抵消部分误差，在期望意义下达到更好的近似比。

我第一次接触这个概念是在做集合覆盖问题近似解时，当时觉得这哪里是算法，简直是掷骰子。但多跑了几组实验后服气了：随机舍入配合多次独立运行取最优，效果稳定，而且理论上界有明显保证。虽然竞赛里不常用，但在离线算法研究和工程启发式算法里，它是一种非常优雅的“舍入”策略。

4.3 舍入方向的经验法则

把前面几类经验压缩成一张表，我在写代码前都会快速过一遍：

5. 现场排查：我踩过的舍入坑与速查表

5.1 eps 选得太大，同一点被判到两侧

有一回我在做两个圆的交点计算，代码逻辑完全按几何定理来，但很多交点位置出现细微偏差。为了图省事，我把 eps 统一设成了1e-5，结果连锁反应来了：原本相隔1e-6的两个交点被判成同一个点，后续的图形拼接直接错乱。

排查过程花了一个多小时，最后我把输入缩小到最小复现场景，一步步打印中间值，才发现 eps 太大导致归并时吞噬了有效差异。教训是：eps 要看数值量级来定，不能全局一个值写死。如果一个程序里不同模块的误差量级差很多，最好分别定义各自的 eps，而不是共用常量。我在代码里会写类似const double EPS = 1e-10 * max(1.0, maxVal);这样的自适应表达式，让 eps 随输入规模缩放。

5.2 负数离散化时的截断错位

另一个亲历的坑来自区间映射。当时做的是线段树离散化，坐标可能是负数，也可能是浮点。我图快用了int id = x;直接截断，导致-1.7变成-1，而我希望得到的是 floor 后的-2。排序后的坐标序列因此出现了“越界访问”和“命中错误区间”两个诡异症状。

改成int id = (int)floor(x);之后一切恢复正常。从那时起，我看到任何“double 转 int”的代码都本能地警觉，会先确认变量的取值范围和预期舍入方向。在团队 code review 里，我也会专门问一句：这里的截断是你想要的吗？这个短短的问句曾经阻止了好几个事故。

5.3 排查速查表

我把常见的舍入相关 bug 整理成一个速查表，排查时直接对着看，效率比从头苦想高很多：

5.4 调试舍入问题的小技巧

除了速查表，我再分享两个亲测好用的调试手段。第一，把关键中间值以高精度打印出来，比如 C++ 里用cout << setprecision(17)输出完整浮点表示，很多误差在 17 位精度下无处遁形。第二，对取整函数写一个小的“边界测试集”，把-3.5、-2.0、-0.1、0.0、0.1、2.5、3.7这些典型值全部跑一遍，确认只改了一个方向、没改坏另一个方向。这类边界测试我已经养成习惯，每次封装新的取整工具都会跑一遍，比事后 debug 省时得多。

我个人在实际操作中的体会是：舍入不是代码的边缘细节，而是一个贯穿需求和实现的决策点。我如今写几何相关代码的第一反应是“能不能全用整数”；必须用浮点时，第一件事是量级估算并定好 epsilon；涉及分桶和离散化，一定会确认负数范围和取整方向。这套从坑里总结出来的工作流，帮我避免了很多投入产出比极低的精度追杀战。希望这些经验也能让拿到这份总结的你，在下一次被“差一点点就错”的问题困住时，少走几小时弯路。