PHP 和 Lua 对数函数非单调性：计算方法差异引发的奇怪现象？

【对数函数的异常现象】2026 年 7 月 22 日的研究发现如果 ab1 且 x1理论上 logₐx log_bx。这很好理解对于“常规”数字a 越大要得到相同的 x所需的 t 就越小。然而PHP 在少数罕见情况下会认为这个结论是错的。代码示例如下php ?php $x 2.93; $a 10 2 ** -49; $b 10; assert($a $b); var_dump(log($x, $a) log($x, $b)); var_dump(log($x, $a) log($x, $b));这可不是常见的浮点数精度问题这个例子是特意设计来触发不同问题的。要是计算结果显示 logₐx log_bx其实也合理因为并非所有实数都能精确表示为浮点数四舍五入可能让相近结果看起来相等。比如在 Python 中用同样数字调用 math.log 函数就是“相等”结果。但在 PHP 和 Lua 中结果却反转了可在 Rust 或 C# 中就不会而且还是在同一台机器和操作系统上这是为啥呢另外若只改变对数底数会发现很多在任何语言中都会出现的反例比如plaintext log(243 ** 3, 3 ** 3) ! log(243, 3)这是因为 log 函数计算公式不完美但这不是本文重点。【对数的底数与计算方法】为搞清为啥会这样先看看各种编程语言通常是如何实现 math.log 函数的。不过 libc 有多种独立实现方式。libm 库提供了超越函数包含多个计算对数的函数像 log、log10、log2 等每个函数处理一种特定底数。虽然不能保证精度但通常不错还至少是单调的。然而没有一个函数能处理任意底数的对数所以提供双参数 log 函数的编程语言只能另辟蹊径。从数学角度讲logₐx ln x / ln a所以可以通过两个以 e 为底的对数来计算任意对数。但这种方法会有一点不精确这就是 math.log(243^3, 3^3) math.log(243, 3) 不成立的原因。不过这解释不了本文开头真数不变的情况在那个例子里分子不变分母变小了结果却变小了这太奇怪了就算考虑浮点数特性也说不通更怪的是在 PHP 或 Lua 中实际计算 ln a 和 ln b 时会发现它们四舍五入后的值一样。也就是说分子和分母都没变但结果却变了这咋回事呢【解决方案与原因剖析】原因可能是 b 10 是个特殊反例而且在双 log 精度误差中有个可疑的与 log10 相关的漏洞。PHP 和 Lua 并非总是用 ln x / ln a 这个公式。对于 libm 直接实现的底数也就是底数 10 和底数 2它们会直接调用相应的函数而不通过自然对数来计算。所以上述代码比较的并非两个 ln x / ln a 的计算结果而是 log(x) / log(10 eps) 和 log10(x)。由于这是两种完全不同的计算方法出现不同方向的误差也就不足为奇了。这样做初衷是好的log10 在适用情况下能提供更精确、更快速的结果。但将两种计算方法结合起来会在边界处产生不连续性从而打破了这两种方法各自满足的合理假设【杂谈与思考】这不一定算个 bug但确实是个容易被忽视的问题。在浮点数的世界里这种情况很常见IEEE - 754 标准本身可靠但一些考虑不周的实现决策影响了它以至于人们常把浮点数问题归咎于其内在不精确性。对于只提供 math.log 而不提供 math.log10 的 Lua 来说正确做法应该是添加 math.log10 函数并去掉 math.log 中的特殊处理。这样使用固定底数 10 的用户能使用更快速、更简单的方法获得更好的精度使用可变底数的用户也不用担心边界情况。但 Lua 5.2 几乎做了完全相反的事情不过还是很欣赏他们对正确性的重视。另一方面PHP 尽管已有 log10 函数但仍然对底数 10 和 2 进行特殊处理据说是为了照顾不看文档的用户。如果真有人会疯狂到去猜测 PHP 函数名那这个目标受众倒也说得过去。真是让人摸不着头脑啊有趣的是PHP 和 C# 还会对 log(x, 1) 进行特殊处理无论 x 为何值都会返回 NaN而 Lua 和 Python 通常会返回 ±∞。这真是一个多样化的生态系统啊。还有PHP 的 log 函数签名表明默认底数是 e 的近似值但文档又说不带底数的 log 函数返回自然对数。那么 log(x) 计算的是 log_rounded(e)x 还是 logₑx 呢这个问题比看起来更重要。至少 Lua 还比较委婉地含糊其辞。剧透一下答案是后者但实际上 log(x, M_E) 也会产生相同的结果因为 ln x / ln a 中的四舍五入误差太大导致两者结果一致。【亲手打造为啥呢】此处原文未展开留给大家思考为啥要亲手打造呢