Somewhat interesting, 123456789 * 8 is 987654312 (the last two digits are swapped). This holds for other bases as well: 0x123456789ABCDEF * 14 is 0xFEDCBA987654312.
Also, adding 123456789 to itself eight times on an abacus is a nice exercise, and it's easy to visually control the end result.
I also went about looking at the difference rather than the order. In the hexadecimal case, the difference is 15 (0xEF vs 0x12). I thought, then, that for any base B with ascending digits A and descending digits D, (D-(B-1))/A=B-2.
For binary, it looks like (1-(b-1))/1=b-10 or (1-(2-1))/1=2-2=0 in decimal.
For trinary, it looks like (21-(b-1))/12=b-2 or (7-(3-1))/5=5/5=1 in decimal.
For quaternary, it looks like (321-(b-1))/123=b-2 or (57-(4-1))/27=54/27=2 in decimal.
Essentially and perhaps unsurprisingly, the size of the slices in the number pie get smaller the bigger the pie gets. In binary, the slice is the pie, which is why the division comes out to zero there.
Why the b > 2 condition? In the b=2 case, all three formulas also work perfectly, providing a ratio of 1. And this is interesting case where the error term is integer and the only case where that error term (1) is dominant (b-2=0), while the b-2 part dominates for larger bases.
In base 2 (and only base 2), denom(b) >= b-1, so the "fractional part" (b-1)/denom(b) carries into the 1's (units) place, which then carries into the 2's (b's) place, flipping both bits.
I remember seeing that (14787 + 36989) / 2 would produce 25888, in that the mean of geometric shape traced by the two sequences would average out in the middle like that
the design of a keypad... it unintentionally contains these elegant mathematical relationships.
i call this phenomena: outcomes of human creations can be "funny and odd", and everybody understand that eventually there will be always something unpredictable.
Great, now I'm getting Carrot Top flashbacks. "Dial right down the center of the phone!"
For non-Americans and/or those too young to remember when landline service was still dominant, in the 90s and early 2000s AT&T ran a collect-call service accessible through the number 1-800-CALL-ATT (1-800-225-5288) and promoted it with ads featuring comedian Carrot Top. And if you don't know who Carrot Top is, maybe that's for the best.
This is a fantastic observation, and yes, this pattern not only continues for larger bases, but the approximation to an integer becomes dramatically better.
The general pattern you've found is that for a number base $b$, the ratio of the number formed by digits $(b-1)...321$ to the number formed by digits $123...(b-1)$ is extremely close to $b-2$.
### The General Formula
Let's call your ascending number $N_{asc}(b)$ and your descending number $N_{desc}(b)$.
The exact ratio $R(b) = N_{desc}(b) / N_{asc}(b)$ can be shown to be:
The "error" or the fractional part is that second term. As you can see, the numerator $(b-1)^3$ is roughly $b^3$, while the denominator $b^b$ grows much faster.
Sign:
The approximation with denominator b^b underestimates the exact value.
Digit picture in base b:
(b - 1)^3 has base-b digits (b - 3), 2, (b - 1).
Dividing by b^b places those three digits starting b places after the radix point.
Examples:
base 10: 8 + 9^3 / 10^10 = 8.0000000729
base 9: 7 + 8^3 / 9^9 = 7.000000628 in base 9
base 8: 6 + 7^3 / 8^8 = 6.00000527 in base 8
num(b) / denom(b) equals (b - 2) + (b - 1)^3 / (b^b - b^2 + b - 1) exactly.
Replacing the denominator by b^b gives a simple approximation with relative error exactly (b^2 - b + 1) / b^b.
This was by far the most interesting part to me. I've never considered that code and proofs can be so complementary. It would be great if someone did this for all math proofs!
"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."
The other replies are good, but let's add another one anyway.
0.987654321/0.123456789 = (1.11111111-x)/x = 1.11111111/x - 1 where x = 0.123456789
You can aproxímate 1.11111111 by 10/9 and aproxímate x = 0.123456789 using y = 0.123456789ABCD... = 0.123456789(10)(11)(12)(13)... that is a number in base 10 that is not written correctly and has digits that are greater than 9. I.E. y = sum_i>0 i/10^i
Now you can consider the function f(t) = t + 2 t^2 + 3 t^3 + 4 t^4 + ... = sum_i>0 i*t^i and y is just y=f(0.1).
And also consider an auxiliary function g(t) = t + t^2 + t^3 + t^4 + ... = sum_i>0 1*t^i . A nice property is that g(t)= 1/(1-t) when -1<t<1.
The problem with g is that it lacks the coefficients, but that can be solved taking the derivative. g'(t) = 1 + 2 t + 3 t^2 + 4 t^3 + ... Now the coefficients are shifted but it can be solved multiplying by t. So f(t)=t*g'(t).
So f(t) = t * (1/(1-t))' = t * (1/(1-t)^2) = t/(1-t)^2
Now add some error bounds using the Taylor method to get the difference between x and y, and also a bound for the difference between 1.11111111 an 10/9. It shoud take like 15 minutes to get all the details right, but I'm too lazy.
(As I said in another comment, all these series have a good convergence for |z|<1, so by standards methods of complex analysis all the series tricks are correct.)
So 987,654,321 + 2 x 123,456,789 \approx 10 x 123,456,789
Thus 987,654,321 / 123,456,789 \approx 8.
If you squint you can see how it would work similarly in other bases. Add the 123... equivalent once to get the base-independent series of 1's, add a second time to get the base-independent 123...0.
48 comments
[ 4.6 ms ] story [ 76.0 ms ] thread[0] https://mathworld.wolfram.com/RamanujanConstant.html
Base 3: 21/12 = 7/5(dec.)
Base 2: 1/1 = 1
Base 1: |/| = 1 (thinking |||| = 4 etc.)
Also, adding 123456789 to itself eight times on an abacus is a nice exercise, and it's easy to visually control the end result.
They are also +9 away from being in order.
And then 12345678 * 8 is 98765424 which is +9 away from also being in order.
For binary, it looks like (1-(b-1))/1=b-10 or (1-(2-1))/1=2-2=0 in decimal.
For trinary, it looks like (21-(b-1))/12=b-2 or (7-(3-1))/5=5/5=1 in decimal.
For quaternary, it looks like (321-(b-1))/123=b-2 or (57-(4-1))/27=54/27=2 in decimal.
Essentially and perhaps unsurprisingly, the size of the slices in the number pie get smaller the bigger the pie gets. In binary, the slice is the pie, which is why the division comes out to zero there.
pp = lambda x : denom(x)/ (num(x) - denom(x)*(x - 2))
[pp(2),pp(4),pp(6),pp(8)]
[1.0, 9.0, 373.0, 48913.0]
* David Goldberg, 1991: https://dl.acm.org/doi/10.1145/103162.103163
* 2014, "Floating Point Demystified, Part 1": https://blog.reverberate.org/2014/09/what-every-computer-pro... ; https://news.ycombinator.com/item?id=8321940
* 2015: https://www.phys.uconn.edu/~rozman/Courses/P2200_15F/downloa...
In base 2 (and only base 2), denom(b) >= b-1, so the "fractional part" (b-1)/denom(b) carries into the 1's (units) place, which then carries into the 2's (b's) place, flipping both bits.
741 + 369 & 963 + 147 | 123 + 987 & 321 + 789 (left right | up down)
159 + 951 & 753 + 357 | 258 + 852 & 456 + 654 (diagonally | center lines)
the design of a keypad... it unintentionally contains these elegant mathematical relationships.
i call this phenomena: outcomes of human creations can be "funny and odd", and everybody understand that eventually there will be always something unpredictable.
(147 + 369) / 2 = 258
and
(741 + 963) / 2 = 852
For non-Americans and/or those too young to remember when landline service was still dominant, in the 90s and early 2000s AT&T ran a collect-call service accessible through the number 1-800-CALL-ATT (1-800-225-5288) and promoted it with ads featuring comedian Carrot Top. And if you don't know who Carrot Top is, maybe that's for the best.
11 * 11 = 121
111 * 111 = 12321
1111 * 1111 = 1234321
and so on, where the largest digit in the answer is the number of digits in the multiplicands.
https://gemini.google.com/share/1e59f734b43c
This is a fantastic observation, and yes, this pattern not only continues for larger bases, but the approximation to an integer becomes dramatically better.
The general pattern you've found is that for a number base $b$, the ratio of the number formed by digits $(b-1)...321$ to the number formed by digits $123...(b-1)$ is extremely close to $b-2$.
### The General Formula
Let's call your ascending number $N_{asc}(b)$ and your descending number $N_{desc}(b)$.
The exact ratio $R(b) = N_{desc}(b) / N_{asc}(b)$ can be shown to be:
$$R(b) = (b-2) + \frac{(b-1)^3}{b^b - b^2 + b - 1}$$
The "error" or the fractional part is that second term. As you can see, the numerator $(b-1)^3$ is roughly $b^3$, while the denominator $b^b$ grows much faster.
### Testing Your Examples
Let's check your two examples with this formula:
* *Base 10 (b=10):* * $R(10) = (10-2) + \frac{(10-1)^3}{10^{10} - 10^2 + 10 - 1}$ * $R(10) = 8 + \frac{9^3}{10,000,000,000 - 91}$ * $R(10) = 8 + \frac{729}{9,999,999,909} \approx 8 + 0.0000000729...$ * This matches your $8.0000000729$ perfectly.
* *Base 6 (b=6):* * $R(6) = (6-2) + \frac{(6-1)^3}{6^6 - 6^2 + 6 - 1}$ * $R(6) = 4 + \frac{5^3}{46,656 - 31}$ * $R(6) = 4 + \frac{125}{46,625} \approx 4 + 0.00268...$ * This also matches your $4.00268$.
### Answering Your Question: A Larger Base
So, what about a larger base? Let's use *Base 16* (hexadecimal), which uses digits $1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F$. Here, $b=16$.
* $N_{asc} = 123456789ABCDEF_{16}$ * $N_{desc} = FEDCBA987654321_{16}$
According to the pattern, the ratio should be extremely close to $b-2 = 16-2 = 14$.
Let's use the formula to see how close:
* $R(16) = (16-2) + \frac{(16-1)^3}{16^{16} - 16^2 + 16 - 1}$ * $R(16) = 14 + \frac{15^3}{16^{16} - 241}$ * $R(16) = 14 + \frac{3,375}{1.844... \times 10^{19} - 241}$ * $R(16) \approx 14 + (1.829... \times 10^{-16})$
So, the ratio in base 16 is approximately: *$14.0000000000000001829...$*
As you predicted, the "error" for a larger base is astronomically smaller than it was for base 10.
Exact relation: num(b) - (b - 2)denom(b) = b - 1
Therefore: num(b) / denom(b) = (b - 2) + (b - 1)^3 / (b^b - b^2 + b - 1) [exact]
Geometric expansion: Let a = b^2 - b + 1. 1 / (b^b - b^2 + b - 1) = (1 / b^b) * 1 / (1 - a / b^b) = (1 / b^b) * sum_{k>=0} (a / b^b)^k
So: num(b) / denom(b) = (b - 2) • (b - 1)^3 / b^b • (b - 1)^3 * a / b^{2b} • (b - 1)^3 * a^2 / b^{3b} • …
Practical approximation: num(b) / denom(b) ≈ (b - 2) + (b - 1)^3 / b^b
Exact error: Let T_exact = (b - 1)^3 / (b^b - b^2 + b - 1) Let T_approx = (b - 1)^3 / b^b
Absolute error: T_exact - T_approx = (b - 1)^3 * (b^2 - b + 1) / [ b^b * (b^b - b^2 + b - 1) ]
Relative error: (T_exact - T_approx) / T_exact = (b^2 - b + 1) / b^b
Sign: The approximation with denominator b^b underestimates the exact value.
Digit picture in base b: (b - 1)^3 has base-b digits (b - 3), 2, (b - 1). Dividing by b^b places those three digits starting b places after the radix point.
Examples: base 10: 8 + 9^3 / 10^10 = 8.0000000729 base 9: 7 + 8^3 / 9^9 = 7.000000628 in base 9 base 8: 6 + 7^3 / 8^8 = 6.00000527 in base 8
num(b) / denom(b) equals (b - 2) + (b - 1)^3 / (b^b - b^2 + b - 1) exactly. Replacing the denominator by b^b gives a simple approximation with relative error exactly (b^2 - b + 1) / b^b.
"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."
In general, sum(x^k, k=1…n) = x(1-x^n)/(1-x).
Then sum(kx^(k-1), k=1…n) = d/dx sum(x^k, k=1…n) = d/dx (x(1-x^n))/(1-x) = (nx^(n+1) - (n+1)x^n + 1)/(1-x)^2
With x=b, n=b-1, the numerator as defined in TFA is n = sum(kb^(k-1), k=1…b-1) = ((b-2)b^b + 1)/(1-b)^2 = ((b-2)b^b + 1)/(1-b)^2.
And the denominator is:
d = sum((b-k)b^(k-1), k=1..b-1) = sum(b^k, k=1..b-1) - sum(kb^(k-1), k=1..b-1) = (b-b^b)/(1-b) - n = (b^b - b^2 + b - 1)/(1-b)^2.
Then, n-(b-1) = (b^(b+1) - 2b^b - b^3 + 3b^2 - 3b +2)/(1-b)^2.
And d(b-2) = the same thing.
So n = d(b-2) + b - 1, whence n/d = b-2 + (b-1)/d.
We also see that the dominant term in d will be b^b/(1-b)^2 which grows like b^(b-2), which is why the fractional part of n/d is 1 over that.
I disagree with the author that a script works as well as a proof. Scripts are neither constructive nor exhaustive.
Pick an integer between 1 and 9. Multiple it by 9. Take that number and multiply it by 12345679. (Skip the 8)
>>> 3 * 9
27
>>> 12345679 * 27
333333333
This all works because:
>>> 111111111 / 9
12345679.0
How do you get around limitations like that in science?
Okay. Try this (in a Python terminal session):
>>> 111111111 ** 2
12345678987654321
(typo corrected)
0.987654321/0.123456789 = (1.11111111-x)/x = 1.11111111/x - 1 where x = 0.123456789
You can aproxímate 1.11111111 by 10/9 and aproxímate x = 0.123456789 using y = 0.123456789ABCD... = 0.123456789(10)(11)(12)(13)... that is a number in base 10 that is not written correctly and has digits that are greater than 9. I.E. y = sum_i>0 i/10^i
Now you can consider the function f(t) = t + 2 t^2 + 3 t^3 + 4 t^4 + ... = sum_i>0 i*t^i and y is just y=f(0.1).
And also consider an auxiliary function g(t) = t + t^2 + t^3 + t^4 + ... = sum_i>0 1*t^i . A nice property is that g(t)= 1/(1-t) when -1<t<1.
The problem with g is that it lacks the coefficients, but that can be solved taking the derivative. g'(t) = 1 + 2 t + 3 t^2 + 4 t^3 + ... Now the coefficients are shifted but it can be solved multiplying by t. So f(t)=t*g'(t).
So f(t) = t * (1/(1-t))' = t * (1/(1-t)^2) = t/(1-t)^2
and y = f(0.1) = .1/.9^2 = 10/81
then 0.987654321/0.123456789 ~= (10/9-y)/y = 10/(9y)-1 = 9 - 1 = 8
Now add some error bounds using the Taylor method to get the difference between x and y, and also a bound for the difference between 1.11111111 an 10/9. It shoud take like 15 minutes to get all the details right, but I'm too lazy.
(As I said in another comment, all these series have a good convergence for |z|<1, so by standards methods of complex analysis all the series tricks are correct.)
987,654,321 + 123,456,789 = 1,111,111,110
1,111,111,110 + 123,456,789 = 1,234,567,899 \approx 1,234,567,890
So 987,654,321 + 2 x 123,456,789 \approx 10 x 123,456,789
Thus 987,654,321 / 123,456,789 \approx 8.
If you squint you can see how it would work similarly in other bases. Add the 123... equivalent once to get the base-independent series of 1's, add a second time to get the base-independent 123...0.
> 0xFEDCBA987654321 / 0x123456789ABCDEF
(somehow I'd seen the denotation for years yet never actually known what it was).