987654321 / 123456789

987654321 / 123456789
987654321 / 123456789

原始链接: https://www.johndcook.com/blog/2025/10/26/987654321/

一个有趣的观察是，987654321/123456789 非常接近 8，这并非仅限于十进制。这种现象也存在于其他进制中。在任何进制 *b* (大于 2) 中，由降序数字组成的一个数与由升序数字组成的一个数的比例始终*非常*接近 *b-2*。具体来说，这个比例等于 *b-2* 加上一个 *b-1* 的余数，导致小数部分大约等于 1/b^(b-2)。这解释了为什么十六进制的例子产生了一个看起来完全是 14 的结果——小数部分太小，无法用标准的浮点精度表示。作者通过计算验证了这种模式在高达 1000 的进制中都成立，并指出存在一个直接（但繁琐）的证明。他们提倡将计算演示与证明相结合，因为程序可以发现不同类型的错误，并阐明通常在形式证明中隐含的细节。

这个Hacker News讨论围绕一个有趣的数学现象：下降数字序列（如987654321）与上升数字序列（123456789）的比率在十进制中非常接近8，在其他进制中甚至更接近`base - 2`。用户们探索了这个现象，分享了不同进制（如十六进制）的例子，并链接到相关的资源，如OEIS（整数序列在线百科）和Stack Exchange讨论。提供了一个精确的公式，展示了这种关系以及随着进制增加误差的减小。对话还涉及了证明、代码和浮点精度之间的联系，一些用户指出，在正式证明之外，计算演示的价值。最终，这个帖子强调了看似简单的数字序列中一个美丽而意想不到的模式。

原文

I recently saw someone post [1] that 987654321/123456789 is very nearly 8, specifically 8.0000000729.

I wondered whether there’s anything distinct about base 10 in this. For example, would the ratio of 54321_six and 12345_six be close to an integer? The ratio is 4.00268, which is pretty close to 4.

What about a larger base? Let’s try base 16. The expression

0xFEDCBA987654321 / 0x123456789ABCDEF

in Python returns 14. The exact ratio is not 14, but it’s as close to 14 as a standard floating point number can be.

For a base b, let denom(b) to be the number formed by concatenating all the digits in ascending order and let num(b) be the number formed by concatenating all the digits in descending order.

$\begin{align*} \text{num}(b) &= \sum_{k=1}^{b-1} kb^{k-1} \\ \text{denom}(b) &= \sum_{k=1}^{b-1} (b-k)b^{k-1} \end{align*}$

Then for b > 2 we have

$\frac{\text{num}(b)}{\text{denom}(b)} = b - 2 + \frac{b-1}{\text{denom}(b)}$

The following Python code demonstrates [2] that this is true for b up to 1000.

num = lambda b: sum([k*b**(k-1) for k in range(1, b)])
denom = lambda b: sum([(b-k)*b**(k-1) for k in range(1, b)])

for b in range(3, 1001):
    n, d = num(b), denom(b)
    assert(n // d == b-2)
    assert(n % d == b-1)

So for any base the ratio is nearly an integer, namely b − 2, and the fractional part is roughly 1/b^b−2.

When b = 16, as in the example above, the result is approximately

14 + 16⁻¹⁴ = 8 + 4 + 2 + 2⁻⁵⁶

which would take 60 bits to represent exactly, but a floating point fraction only has 53 bits. That’s why our calculation returned exactly 14 with no fractional part.

[1] I saw @ColinTheMathmo post it on Mastodon. He said he saw it on Fermat’s Library somewhere. I assume it’s a very old observation and that the analysis I did above has been done many times before.

[2] Why include a script rather than a proof? One reason is that the proof is straight-forward but tedious and the script is compact.

A more general reason that I give computational demonstrations of theorems is that programs are complementary to proofs. Programs and proofs are both subject to bugs, but they’re not likely to have the same bugs. And because programs made details explicit by necessity, a program might fill in gaps that aren’t sufficiently spelled out in a proof.