为何强制转换为uint64_t会改变代码的计算结果？

核心原因：浮点数精度限制 + 类型转换顺序不同 #

1. double类型的精度边界

pow(2,i)返回的是double类型（64位浮点数），它的存储结构决定了：

• 尾数部分有52位，加上隐含的最高位1，总共能精确表示53位二进制整数。
• 这意味着：所有小于2^53的整数都可以被double精确存储；但大于等于2^53的整数中，只有能被2^(k-53)整除的数（比如2的整数次幂）才能被精确表示，其他整数会被舍入到最近的可表示值。

2^53是一个关键节点：它是第一个需要54位二进制来表示的整数，但double的精度只能覆盖53位，不过因为它是2的幂次，所以仍然可以精确存储。但2^53 +1这类数就无法精确表示，会被舍入为2^53。

2. 两种累加方式的本质区别

你的代码里，sum和cast_sum的累加逻辑完全不同：

方式一：sum += pow(2,i)

• sum是uint64_t（无符号64位整数），执行加法时，C语言会先把sum隐式转换为double类型，再和pow(2,i)（double）相加，最后把结果转回uint64_t存回sum。
• 当i=52时，sum的值是2^0 + 2^1 + ... + 2^52 = 2^53 -1 = 9007199254740991，这个数正好是double能精确表示的最大连续整数。
• 当i=53时：
  • pow(2,53)返回精确的9007199254740992.0；
  • sum转成double是9007199254740991.0，两者相加得到18014398509481983.0；
  • 但这个数无法用double精确存储（需要54位二进制），会被舍入到最近的可表示值18014398509481984.0；
  • 最后转回uint64_t，sum就变成了18014398509481984，而正确的整数和应该是18014398509481983。
• 后续累加时，sum已经是被舍入后的值，误差会不断放大。

方式二：cast_sum += (uint64_t)pow(2,i)

• 这里先把pow(2,i)的结果转换为uint64_t：因为2的所有整数次幂（2^0到2^63）都能被double精确表示，所以转换后的uint64_t值是完全准确的。
• 之后的累加是纯整数运算，uint64_t可以精确存储所有64位以内的无符号整数，不会有精度损失，所以得到的结果始终正确。

3. 为什么pow(2,53)和(uint64_t)pow(2,53)看起来相同？

因为2^53本身是2的幂次，符合double的精确存储规则，所以转换前后的值完全一致。问题出在累加时的类型转换顺序，而不是pow的结果本身。

你的目标：计算2^0到2^63的和

其实有更简单的方法：根据等比数列求和公式，2^0 + 2^1 + ... + 2^n = 2^(n+1) - 1，所以2^0到2^63的和是2^64 - 1，也就是uint64_t的最大值0xffffffffffffffff，直接赋值即可，不需要循环累加。

内容的提问来源于stack exchange，提问作者Gregory Arenius