★ FEATURED ARTICLE 1. 一道编号1019的题为什么值得专门写一篇上个月我在某刷题平台按编号顺序刷题做到第1019题时愣了一下题目只有五个字浮点数向零舍入。看到题的那一瞬间我的第一反应是“送分题”三分钟就能交卷那种。结果等真正写代码、跑样例、反复提交之后我才发现这四个字背后藏着一整套关于舍入模式、语言差异和边界处理的知识不是一句“截断小数部分”能带过的。这道题的要求很直白输入若干浮点数输出每个数向零舍入后的整数。所谓向零舍入通俗讲就是直接丢掉小数部分正数往小取负数往大取。比如3.7变成3-3.7变成-3而0.9变成0。可是如果你真的只写一句“把小数部分删掉”在C、Python、JavaScript、Java、Rust这些主流语言里结果可能是一样的但边界情况完全不一样稍不留意就被隐藏样例打脸。我这里说的“1019”是某平台上的一道题号题目本身很基础但它非常适合作为一根引线把浮点数舍入、类型转换、语言规范和工程习惯串起来。这篇文章就围绕这道题展开适合三类人看刚开始刷题的初学者、教编程基础课的老师或助教、以及工作里经常和数值计算打交道的开发者。你不需要多高深的前置知识只要写过几行代码能理解“浮点数有小数部分”就够了。1.1 题目到底想要你做什么题目名叫“浮点数向零舍入”但很多人一上来就把“舍入”和“四舍五入”画等号。四舍五入是小学课本里的概念3.5变42.5变3。向零舍入完全不同它的规则是无论正负都朝零的方向找一个最近的整数。换句话说正数的小数部分直接扔掉负数的小数部分也是直接扔掉只不过因为负数的绝对值更接近零所以-3.7会变成-3而不是-4。这个“不是-4”的点是整道题最容易出错的地方。如果你的第一反应是直接套用某些语言里的floor向下取整函数那-3.7会被算成-4样例一跑就挂。题目没有说“不允许调用库函数”也没有限定语言所以理论上你完全可以用语言自带的取整函数。但正因为没限制考察点就落在“你是否知道该用哪个函数”以及“边界输入来时程序会不会崩”。1.2 简单题目背后的三处暗坑第一处暗坑是负数。大多数语言的默认截断行为是向零的比如C语言里(int)(-3.7)通常得到-3Python的int(-3.7)也是-3。但如果你心里想着“取整就是向下取整”就会用floor然后负数的结果就错了。第二处暗坑是溢出。浮点数可以非常大比如1e20这类数值转成32位整数时已经超出int的取值范围。C/C里这种转换结果不是语言标准保证的Java里它会饱和到2147483647各语言表现五花八门。第三处暗坑是非有限数。NaN、正无穷、负无穷传入取整函数时有的语言抛异常有的语言返回NaN有的语言直接返回整数极值。题目如果不明确说明你至少要保证程序不会因为这些输入直接崩溃。2. 向零舍入的本质数轴上三兄弟的关系想真正搞懂向零舍入不能只记结论要在数轴上去看。我当年学的时候总把四个概念混在一起向下取整、向上取整、向零舍入、四舍五入。后来用一条数轴画了一遍这辈子都不会再混了。2.1 “向下”“向上”“向零”在负数区域的分岔口向下取整floor数学定义是“不大于x的最大整数”。-3.7的floor是-4因为-4比-3.7小而且是整数。向上取整ceil是“不小于x的最小整数”-3.7的ceil是-3。向零舍入truncate是“在数轴上往零的方向找整数”-3.7离零最近的整数是-3。正数那边三者还挺和睦3.7的floor和truncate都是3ceil是4。一到负数floor和truncate立刻分裂floor(-3.7) -4truncate(-3.7) -3。这条规律可以写成一句话向零舍入等价于正数向下取整、负数向上取整。我见过有人专门为这个头疼说“Curious case of negative numbers”。其实你只要记住一个画面数轴上的0是中心向零舍入就是无论你站在数轴哪一边都往中心迈一步把小数部分丢掉。反过来向下取整是永远往左走不管你在正数区还是负数区都往更小的方向走。一个是“拉向0”一个是“推向负无穷”碰到负数自然就分道扬镳了。2.2 IEEE 754里的舍入模式与浮点转换的关系浮点数在计算机里遵循IEEE 754标准这个标准里规定了好几种舍入模式最近偶数舍入round to nearest, ties to even、向正无穷舍入、向负无穷舍入、向零舍入。默认的浮点运算舍入是“最近偶数舍入”这主要是用来控制浮点算术精度的。比如两个浮点数相加结果落在两个可表示数之间就选最容易偶数尾数那个。但是“浮点数转整数”这件事和“浮点运算舍入”是两码事。绝大多数CPU的浮点转整数指令做的是向零截断也就是直接丢掉小数部分。这也是为什么C语言里写(int)3.7得到3写(int)-3.7得到-3硬件层面就这么设计的。很多语言的设计者顺着这个语义把浮点转整数的默认行为设置成向零舍入。需要强调的是IEEE 754默认的四舍五入到最近偶数和向零舍入不是一个东西。3.5按四舍五入是4按向零舍入是3-3.5按向零舍入是-3。如果你在代码里写round函数那是“四舍五入到最近整数”不是“向零舍入”。所以题目里一旦出现“向零舍入”round、floor、ceil全都不对口只有truncate相关的API或类型强转才是正解。2.3 为什么“四舍五入”在这里是错的四舍五入对正数是“大于等于0.5进一位”向零舍入对正数是“不管小数多少都丢掉”。在正数3.7上四舍五入是4向零舍入是3。哪怕3.999向零舍入也是3只有整数3.0才留在3。这个差距在做数值处理时非常致命。我给你打个比方向零舍入是“截断管子”四舍五入是“水满则溢”。比如一批商品重量按整数千克结算如果老板用四舍五入3.6千克的货要按4千克收钱如果他用向零舍入3.6千克按3千克收钱。两种规则在财务语义上完全不同代码里写错一个舍入方向结果可能差出整整一个数量级。这也是为什么很多接口文档里会明确标注truncate或round half up工程师一看就懂该用哪个。3. 多语言实现对照同一个API藏着不同脾气原理归原理真到写代码的时候不同的语言给了不同的API而且它们的边界行为各有各的脾气。我把常用的几种语言都试了一遍下面是实测记录。3.1 C/C类型强转与trunc的分工C语言里最直接的写法是浮点数强转成整数double x -3.7; int a (int)x; // 常见平台上得到 -3 int b (int)trunc(x); // 明确向零得到 -3 int c (int)floor(x); // 得到 -4这是向下取整(int)x在几乎所有现代编译器、常见CPU上表现都是向零截断但严格按C/C标准浮点数转整数时如果目标值无法表示行为是未定义的。负数本身通常没问题可一旦x是NaN、无穷大或者1e20这种大数结果就不可预测。所以稳妥的做法是先判断isfinite再强转。C11之后可以直接用std::trunc把小数部分截掉它返回的还是浮点数想变成int还要再强转一次。实话说C/C里我更喜欢用trunc而不是直接强转至少代码自文档化了读代码的人看到trunc就知道是“向零”看到(int)可能还要想一下是“向零还是实现定义”。3.2 Pythonint()天然就是向零舍入Python里最省事的就是int()import math int(-3.7) # -3 math.trunc(-3.7) # -3 math.floor(-3.7) # -4向下取整不是题目要的Python的int(浮点数)特意设计成向零舍入底层调用的是__trunc__跟math.trunc一个意思。这个设计很符合日常直觉输入一个带小数点的数字取整时保留整数部分丢掉小数部分。但有个大坑int(float(nan))会抛ValueErrorint(float(inf))会抛OverflowError。也就是说Python在非有限数上直接拒绝工作。如果题目在隐藏测试里塞了NaN或Inf你的程序会被未捕获异常打断。所以比较稳的写法是import math def trunc_to_int(x: float) - int: if not math.isfinite(x): raise ValueError(input must be finite) return int(x)或者按题目要求返回一个约定的特殊值比如0。总之不能假设输入永远正常。3.3 JavaScript与Java饱和和NaN的态度各不相同JavaScript的Math.trunc名字最直白Math.trunc(-3.7); // -3 Math.floor(-3.7); // -4需要注意Math.trunc(NaN)返回NaNMath.trunc(Infinity)返回Infinity它不会抛异常也不会帮你转成整数类型。如果你的业务逻辑要求最终结果一定是“整数类型”那得自己再判一遍有限性。另一个容易踩的坑是parseInt(-3.7)parseInt本质是给字符串用的它会先把参数转成字符串再解析在这里恰好返回-3但拿它当取整函数用是错误姿势遇到parseInt(0.0000001)这类场景结果会非常抽象。Java的写法是(int)强转int a (int) -3.7; // -3 double d Math.floor(-3.7); // -4.0Java语言规范把浮点转整数的行为写得很死向零截断超出范围时饱和到Integer.MAX_VALUE或Integer.MIN_VALUENaN转int时直接变0。所以Java在处理NaN时反而不会崩但你要知道这个“0”是规范约定的不是数学上有意义的结果。3.4 Go与Rust现代语言的态度与平台差异Go里直接写int(-3.7)语言规范明确是向零截断。但Go的规范同样没有把非有限数转换的细节完全写死在不同CPU架构上跑出来的值可能不一样有时是平台相关的垃圾值。我建议在Go里也养成先判断math.IsNaN和math.IsInf的习惯。Rust用as转换let a: i32 -3.7_f64 as i32; // -3Rust从1.45版本开始as转换浮点数到整数采用饱和语义NaN变0超出范围的无穷大会饱和到i32的最大值或最小值。这比C/C的未定义行为友好得多也比Go清晰。但如果题目要求你“实现”向零舍入而不是要求“调用库”Rust的as一样能用核心注意点同样是先处理NaN和Inf。下面这张表把几种常见语言的核心差别列出来方便你快速对照语言向零舍入写法-3.7的结果NaN处理态度Infinity处理态度C/C(int)x或trunc(x)-3未定义/需要自行判断未定义/需要自行判断Pythonint(x)/math.trunc(x)-3抛 ValueError抛 OverflowErrorJavaScriptMath.trunc(x)-3返回 NaN返回 InfinityJava(int)x-3返回 0饱和到 int 极值Goint(x)-3平台相关建议先判断平台相关建议先判断Rustx as i32-3返回 0饱和到 i32 极值看完这张表你就能明白同样一句“向零舍入”到边界输入那里各个语言给了完全不同的答案。这也是工程里写数值工具库时特别要注意的地方接口文档不能只写“取整”最好把NaN、Infinity、溢出的行为全部写清楚。4. 不调用库手写向零舍入我踩过的实验坑有些题目会明确要求“不要使用库函数”或者你在某些嵌入式环境里根本没有现成API。这时候就得手写向零舍入。我一开始以为随便写两行就行结果被测试数据反复教育了好几轮。4.1 我第一版错误方案为什么不能简单“减0.5”我最初的思路是既然向零舍入等于“把小数部分去掉”那我用“减0.5再向下取整”能不能实现正数似乎可行3.7减0.5等于3.2向下取整是3。但换到负数立刻翻车-3.7减0.5等于-4.2向下取整是-5正确答案是-3差了十万八千里。这个错误的根源是把“向零舍入”和“四舍五入的近似手段”混在了一起。四舍五入可以用“正数加0.5再floor、负数减0.5再floor”这种技巧但向零舍入压根不是这么定义的。向零舍入的正确等价写法是“正数向下取整负数向上取整”也就是int trunc_to_int(double x) { if (isnan(x) || isinf(x)) { // 按业务约定返回特定值比如 0 return 0; } return x 0 ? (int)floor(x) : (int)ceil(x); }用Python表达更明显import math def trunc_to_int(x): if not math.isfinite(x): raise ValueError(non-finite input) return math.floor(x) if x 0 else math.ceil(x)这段代码里没有直接调用trunc但数学语义完全一致。我第一次看到这种写法时愣了一下然后才反应过来条件表达式本质上就是在“往零的方向拉”。4.2 边界值实验-0.0、NaN、Infinity让我重写了三版第二次写的时候我在本地加了几个自以为很全面的用例-3.7、-3.0、-0.7、0.999、2.5、-2.5、3.7。测完都对了我很自信地提交结果还是挂了一个边界点。事后复盘是-0.0这个输入。-0.0在IEEE 754里是一个合法的负零浮点数。按向零舍入它应该输出整数0但某些实现里如果你用x 0 ? ... : ...判断-0.0 0在C语言里为真所以会走进正数分支floor(-0.0)仍然是-0.0再转成int还是0。表面看没问题。可如果你手写的是“判断x是否小于0然后走ceil分支”-0.0可能被当成负数处理最终返回-0.0再转整数时在某些语言里结果是0在另一些语言里会出现奇怪的符号位残留。更麻烦的是NaN和Infinity。我把trunc_to_int的测试表里补上这两项之后输入正确预期我第一版实现的结果问题-3.7-3-3正常-3.0-3-3正常-0.700正常0.99900正常2.522正常-2.5-2-2正常3.733正常-0.000正常但代码里语义不够明确NaN未定义但不能崩返回0取决于判断顺序需要约定Infinity未定义但不能崩返回int极值或垃圾值需要显式判断-Infinity未定义但不能崩返回int极值或垃圾值需要显式判断C语言里直接拿NaN和Infinity强转int在很多平台上是未定义行为程序可能不会立刻崩溃但会给你一个毫无道理的数。在Python里则是直接抛异常。所以最终实现时必须把“非有限数”单独拎出来处理不管返回0还是抛异常都要让行为可控。4.3 一个能扛住隐藏测试的稳定版经过几轮修改我最终敲定的版本长这样以Python为例import math def truncate_toward_zero(x: float) - int: # 非有限数显式处理避免 int() 抛 OverflowError / ValueError if math.isnan(x) or math.isinf(x): raise ValueError(cannot truncate non-finite value) return int(x)在C语言里稳妥版本是#include math.h int truncate_toward_zero(double x) { if (!isfinite(x)) { // 按业务约定返回这里返回 0 仅作示意 return 0; } return (int)x; // 常见平台向零截断 }核心不是某个函数而是三个动作先判断有限性再明确语义最后才做转换。这个顺序能帮你避开绝大多数隐藏测试。顺便说一句如果你把int(x)替换成math.floor(x)负数的输出就会全部偏成-4所以Python的int()在这里就是最正确、最省事的答案。5. 从1019延伸出的三个编码习惯刷完1019这道题我不只是记住了“向零舍入用trunc”它逼我反思了几个平时不太注意的编码细节。这些习惯不是题目的内容但比题目本身更能影响日常开发质量。5.1 写清楚“舍入模式”而不是笼统说“取整”我在审查代码时见过很多变量名和函数名叫toInt、cutValue、convert注释里写“转整数”。这种表述对读者没有任何信息量因为“转整数”至少有四种语义向下取整、向上取整、向零舍入、四舍五入。写代码的时候函数名最好直接带上舍入语义比如round_toward_zero、truncate_to_int一眼就知道行为。这背后其实是个工程沟通问题舍入方向是数值处理里的业务规则不是技术实现细节。订单金额、库存数量、评分统计选错舍入模式就是线上事故。函数命名和注释里把这些规则写死比事后排查强得多。5.2 测试用例里永远带上负数和边界值以前我写工具函数测试用例经常是1、2、3这种正数偶尔加个0.5。1019这道题让我长记性了只要是数值处理函数测试集合至少要包含三类数据。第一类是负数特别是-0.7、-3.7这种绝对值不满1或超过1的数第二类是符号边界包括0、-0.0以及在正负之间切换的点第三类是极端值包括NaN、Infinity、非常大的浮点数。列一个可复用的“数值取整测试模板”正整数带小数3.7 - 3负整数带小数-3.7 - -3小数绝对值小于10.7 - 0-0.7 - 0整数值浮点3.0 - 3-3.0 - -3符号边界-0.0 - 0非有限数NaN、Infinity按约定处理且不崩溃溢出值1e20转int后按语言规则处理你在代码里为每种语言准备好这样一张测试表能拦住绝大多数“我以为没问题”的提交。5.3 小题也不要做重复造轮子但要会拆轮子很多初学者看到这题会陷入一种纠结用库函数会不会显得很菜手写是不是更显水平我的看法是分场景。正常业务开发里标准库的trunc、int()、Math.trunc就是最优解它们经过无数人验证还处理了硬件细节。你非要自己用floor/ceil拼一遍只会增加出bug的概率。但如果你的目标是学习那就要会“拆轮子”。把题目的要求拆成原理再亲手实现一遍比如用floor/ceil条件组合或者自己按整数部分处理NaN。这不叫重复造轮子而叫理解轮子。1019这题之所以值得写一篇文章恰恰是因为它在“用库”和“造库”之间搭了一座桥你既可以直接用API也可以从原理上解释API做了什么事。最后再分享一个小技巧。刷题平台通常允许你反复提交同一道题我建议你用至少两种语言各写一遍把-3.7、NaN、Infinity的打印结果都跑出来对比。你会发现背十遍API文档都不如这样实际对比一次来得深刻。起码在这个“浮点数向零舍入”的问题上我是彻底记住了各语言的脾气。
阅读完成 · 觉得有帮助？
