cmath库pow函数异常行为排查：Excel列号计算问题

核心原因 #

你遇到的问题完全是浮点数精度误差导致的：

• pow(26, n)是浮点运算函数，它返回的double类型值并不一定是精确的整数。比如计算pow(26,1)时，实际存储的可能是25.999999999999996而不是精确的26.0。
• 当把这个double值转成int时，C++会直接截断小数部分，25.999999999999996就变成了25，这就是为什么累加后result变成25的原因。
• 本地MinGW GCC 6.3.0的pow实现和在线编译器的版本/优化策略不同，刚好让这个精度误差显现了出来，而在线环境的计算结果碰巧是精确的26.0，所以表现正常。
• 强制类型转换无效的原因是，double本身存储的就不是精确的26，转换只是截断，没法把近似值变精确。

解决方案 #

彻底避免用浮点函数做整数幂运算，改用纯整数实现：

方案1：自己实现整数幂函数 #

int int_pow(int base, int exp) {
    int res = 1;
    for (int i = 0; i < exp; ++i) {
        res *= base;
    }
    return res;
}

调用时用int_pow(26, n)替代pow(26, n)，完全消除浮点误差。

方案2：优化计算逻辑（更高效） #

其实计算Excel列号不需要单独算幂，直接迭代累加即可，逻辑更简洁也更高效：

int titleToNumber(string columnTitle) {
    int result = 0;
    for (char c : columnTitle) {
        result = result * 26 + (c - 'A' + 1);
    }
    return result;
}

比如输入"AA"时，第一次循环result = 0*26 +1=1，第二次result=1*26+1=27，完全符合预期。

浮点数转整数的关键注意事项 #

• 浮点数是近似存储：除了2的整数次幂，大部分整数无法用二进制浮点数精确表示，看起来是整数的数值实际可能是接近它的小数。
• 强制转换是截断不是四舍五入：(int)25.999999得到25，(int)26.0000001得到26，如果要基于四舍五入转换，应该用round()函数，或者手动加0.5后再转换（仅适用于正数场景）。
• 整数运算别碰浮点函数：涉及整数的幂、乘法等运算，优先用纯整数实现，从根源上避免精度问题。
• 不同环境表现可能不一致：不同编译器、标准库版本对浮点函数的实现有差异，本地和在线环境的结果不同是常见情况，不要依赖浮点运算的“偶然精确”。

内容的提问来源于stack exchange，提问作者Satish Kumar Singh