浮点数截断转整数机制疑问：为何4.60与6.60处理结果不同？

这确实是个很有意思的问题，核心在于你对IEEE754浮点数近似方向的误解，以及C语言中浮点数转整型的截断规则。咱们一步步拆解：

1. 先纠正你的误解：IEEE754中4.60和6.60的实际存储值 #

你以为6.60会被存储为6.599999...，但实际上并非如此：

• 对于double类型（atof()返回的是double），4.60的近似值是略小于真实值的，具体是4.5999999999999996447...
• 而6.60的double近似值是略大于真实值的，具体是6.6000000000000005329...

这是因为二进制浮点数无法精确表示所有十进制小数，只能选择最接近的可表示值——4.60的最接近可表示double比它小，而6.60的最接近可表示double比它大。

2. C语言中浮点数转int的截断机制 #

当你把一个浮点数转换为int类型时，C语言采用的是**向零截断（Truncate towards zero）**的规则：简单来说，就是直接舍弃小数部分，只保留整数部分，不管小数部分是0.999...还是0.000...。

3. 针对你的代码具体分析 #

咱们把每一步拆解开：

• 对于int a = atof("4.60") * 100;

  1. atof("4.60")得到~4.5999999999999996
  2. 乘以100后得到~459.99999999999994
  3. 转int时，截断小数部分，结果就是459

• 对于int b = atof("6.60") * 100;

  1. atof("6.60")得到~6.6000000000000005
  2. 乘以100后得到~660.00000000000005
  3. 转int时，截断小数部分，整数部分是660，所以结果就是660

4. 如何避免这类精度问题？ #

如果是处理类似货币这种需要精确十进制表示的场景，推荐几种方案：

• 直接用整数存储最小单位（比如用分来存储金额，而不是元）
• 使用C99标准引入的十进制浮点类型（_Decimal32/_Decimal64），它们专门为十进制小数设计，能避免二进制浮点的精度损失
• 在转换前对浮点数进行四舍五入，比如用round()函数：

  int a = round(atof("4.60") * 100); // 得到460
  int b = round(atof("6.60") * 100); // 得到660
  

内容的提问来源于stack exchange，提问作者Tyler Deng