7 ms·

987654321 / 123456789

• trotro 1y ago
  Feels like a Temu version of Ramanujan's constant [0]. [0] https://mathworld.wolfram.com/RamanujanConstant.html https://mathworld.wolfram.com/RamanujanConstant.html
• MontyCarloHall 1y ago
  In a similar vein, e^pi - pi = 19.9990999792, as referenced in this XKCD: https://xkcd.com/217/ https://xkcd.com/217/
  • madcaptenor 1y ago
    Not really in a similar vein, because there's actually a good reason for this to be very close to an integer whereas there is no such reason for e^pi - pi.
    • tempfile 1y ago
      No known reason :-)
    • deleted 1y ago
      [deleted]
  • zkmon 1y ago
    Also, (-1)^(-i) - pi = 19.999... ;)
• alyxya 1y ago
  I like to think of 0.987654... and 0.123456... as infinite series which simplify to 80/81 and 10/81, hence the ~8 ratio.
  • Stolpe 1y ago
    Care to elaborate? Why does 0.987654 simplify to 80/81 and 0.123456 to 10/81?
    • alyxya 1y ago
      If you set x = 0.123456..., then multiplying it by (10 - 1) gives 9x = 1.111111..., and multiplying it by (10 - 1) again gives 81x = 10, or x = 10/81. I’m not writing things formally here but that’s the rough idea, and you can do the same procedure with 0.987654... to get 80/81.
    • madcaptenor 1y ago
      .123456... = x + 2 x^2 + 3 x^3 + ... with x = 1/10. Then you have (x + 2 x^2 + 3 x^3 + ...) = (x + x^2 + x^3 + x^4 + ...) + (x^2 + x^3 + x^4 + x^5 + ...) + (x^3 + x^4 + x^5 + x^6 + ...) (count the number of occurrences of each power of x^n on the right-hand side) and from the sum of a geometric series the RHS is x/(1-x) + x^2/(1-x) + x^3/(1-x) + ..., which itself is a geometric series and works out to x/(1-x)^2. Then put in x = 1/10 to get 10/81. Now 0.987654... = 1 - 0.012345... = 1 - (1/10) (10/81) = 1 - 1/81 = 80/81.
      • gus_massa 1y ago
        I don't know who downvoted this, but it's correct. The use of series is a little "sloppy", but x + 2 x^2 + 3 x^3 + ... has absolute uniform convergence when |x|<r<1, even more importantly that it's true even for complex numbers |z|<r<1. The super nice property of complex analysis is that you can be almost ridiculously "sloppy" inside that open circle and the Conway book will tell you everything is ok. [I'll post a similar proof, but mine use -1/10 and rounding, so mine is probably worse.]
      • gowld 1y ago
        Don't need the clutter of infinite series and polynomials: 1/9 = 0.1111... 1/81 = 1/9 * 1/9 = 0.111... * 0.111... = Sum of: 0.0111... 0.00111... 0.000111... ... = 0.012345...
        • 1y ago
  • oersted 1y ago
    I didn't get where this comes from until I saw the second answer from the StackOverflow question another commenter shared. https://math.stackexchange.com/a/2268896 https://math.stackexchange.com/a/2268896 Apparently 1/9^2 is well known to be 0.12345679(012345679)... EDIT: Yes it's missing the 8 (I wrote it wrong intially): https://math.stackexchange.com/questions/994203/why-do-we-miss-8-in-the-decimal-expansion-of-1-81-and-98-in-the-decimal-expansi https://math.stackexchange.com/questions/994203/why-do-we-mi... Interesting how it works out but I don't think it is anywhere close to as intuitive as the parent comment implies. The way its phrased made me feel a bit dumb because I didn't get it right away, but in retrospect I don't think anyone would reasonably get it without context.
    • iso1631 1y ago
      9^2 is 81 1/81 is 0.012345679012345679.... no 8 in sight
      • madcaptenor 1y ago
        The 8 is there but then it's followed by a 9 and a 10, and the carry from the 10 ends up bumping it up.
        • zkmon 1y ago
          Shouldn't wee see two zeros then?
          • oersted 1y ago
            This illustrates it nicely: https://math.stackexchange.com/a/994214 https://math.stackexchange.com/a/994214
          • madcaptenor 1y ago
            The reason you don't see two zeroes is as follows: you have .123456789 then add 10 on the end, as the tenth digit after the decimal point, to get .123456789(10) where the parentheses denote a "digit" that's 10 or larger, which we'll have to deal with by carrying to get a well-formed decimal. Then carry twice to get .12345678(10)0 .1234567900 So for a moment we have two zeroes, but now we need to add 11 to the 11th digit after the decimal point to get .1234567900(11) or after carrying .12345679011 and now there is only one zero.
• ozb 1y ago
  More general analytic proof: https://math.stackexchange.com/questions/2268833/why-is-frac987654321123456789-almost-exactly-8 https://math.stackexchange.com/questions/2268833/why-is-frac...
  • ukuina 1y ago
    That question was asked 8 years ago. Coincidence? I think not!
• yohbho 1y ago
  For smaller bases, does this converge to base - 1 ? Base 3: 21/12 = 7/5(dec.) Base 2: 1/1 = 1 Base 1: |/| = 1 (thinking |||| = 4 etc.)
  • incredible1 1y ago
    [dead]
• Joker_vD 1y ago
  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.
  • andyjansson 1y ago
    Another interesting thing is that these seem to work: base 16: 123456789ABCDEF~16 * (16-2) + 16 - 1 = FEDCBA987654321~16 base 10: 123456789~10 * (10-2) + 10 - 1 = 987654321~10 base 9: 12345678~9 * (9-2) + 9 - 1 = 87654321~9 base 8: 1234567~8 * (8-2) + 8 - 1 = 7654321~8 base 7: 123456~7 * (7-2) + 7 - 1 = 654321~7 base 6: 12345~6 * (6-2) + 6 - 1 = 54321~6 and so on.. or more generally: base n: sequence * (n - 2) + n - 1
    • madcaptenor 1y ago
      This is in the original post, in the form num(b)/denom(b) = b - 2 + (b-1)/denom(b) so you just need to clear the denominator.
  • monkpit 1y ago
    > the last 2 digits are swapped They are also +9 away from being in order. And then 12345678 * 8 is 98765424 which is +9 away from also being in order.
    • monkpit 1y ago
      Oops - the second one was supposed to say +8
    • mechanicalpulse 1y ago
      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.
• ok123456 1y ago
  For the even bases, the "error" appears to be https://oeis.org/A051848 https://oeis.org/A051848. 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]
  • madcaptenor 1y ago
    And if you see the description there it traces back to https://oeis.org/A023811 https://oeis.org/A023811, which is more obviously relevant
• throw0101c 1y ago
  See perhaps various "What every programmer / CSist should know about floating-point arithmetic" papers and articles: * David Goldberg, 1991: https://dl.acm.org/doi/10.1145/103162.103163 https://dl.acm.org/doi/10.1145/103162.103163 * 2014, "Floating Point Demystified, Part 1": https://blog.reverberate.org/2014/09/what-every-computer-programmer-should.html https://blog.reverberate.org/2014/09/what-every-computer-pro... ; https://news.ycombinator.com/item?id=8321940 https://news.ycombinator.com/item?id=8321940 * 2015: https://www.phys.uconn.edu/~rozman/Courses/P2200_15F/downloads/floating-point-guide-2015-10-15.pdf https://www.phys.uconn.edu/~rozman/Courses/P2200_15F/downloa...
  • MrOrelliOReilly 1y ago
    As someone who has recently been fighting bugs from representing very simple math with floats... thank you!
• msuvakov 1y ago
  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.
  • listeria 1y ago
    in the b=2 case, you get: 1 / 1 = 1 = b - 1 1 % 1 = 0 = b - 2 they are the other way around, see for example the b=3 case: 21 (base 3) = 7 12 (base 3) = 5 7 / 5 = 1 = b - 2 7 % 5 = 2 = b - 1
    • gowld 1y ago
      In the b=2 case, 1/1 = 1 = (b-2) + (b-1)/denom(b) = (b-2) + (b-1)/1 = 2b - 3 = (b-1)*b^1 -1 (b-1) 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.
• tetris11 1y ago
  I like calculator quirks like this. I remember as a kid playing with the number pad and noticing a geometric center of mass in number sequences ┌───┬───┬───┐ │ 7 │ 8 │ 9 │ ├───┼───┼───┤ │ 4 │ 5 │ 6 │ ├───┼───┼───┤ │ 1 │ 2 │ 3 │ ├───┼───┼───┤ │ 0 │ . │ │ └───┴───┴───┘ 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
  • nashashmi 1y ago
    14789 + 36987 / 2 would do the same thing. Why trace back?
    • dfee 1y ago
      So would 147 and 369. As it’s just an average, per digit, I’m not sure this is very interesting.
      • gowld 1y ago
        Being curious is delightful.
        • huflungdung 1y ago
          [dead]
    • tetris11 1y ago
      Just to show that you could - 14861 and 36843 gives 25852
  • nasvay_factory 1y ago
    i remember the 1110 thing on a calc as well. 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.
• wkat4242 1y ago
  I thought this was a user ID and password lol
• danielbarla 1y ago
  I also spent hours messing around with calculators as a kid. I recall noticing that: 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.
• brutuscat 1y ago
  Gemini thinks in a similar fashion: https://gemini.google.com/share/1e59f734b43c 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.
• OldGreenYodaGPT 1y ago
  Definitions: denom(b) = (b^b - b^2 + b - 1) / (b - 1)^2 num(b) = (b^b(b - 2) + 1) / (b - 1)^2 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.
• jedberg 1y ago
  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."
  • layer8 1y ago
    This is misleading in that the (Curry–Howard) correspondence is between proofs and the static typing of programs. A bug in a proof therefore corresponds to a bug in the static typing of a program (or to the type system of the programming language being unsound), not to any other program bug. (Also: complementary != complimentary.)
    • nh23423fefe 1y ago
      i think this is wrong. code is proofs, types are propositions
      • layer8 1y ago
        The types are the propositions proved by the proof. The proof is correct <=> the program is soundly typed.
      • CamperBob2 1y ago
        Code is proof that the operation embodied by the code works. I don't understand how it proves anything more generally than that, apart from code using exotic languages or techniques intended for just that purpose.
        • sigbottle 1y ago
          Well, in theory (and I guess more generally philosophy) land, sure, you can't really "prove absoluteness" outside of your axioms and assumptions. You need to have a notion of true and false, and then implications, for example, to do logic, then whatever the leap from there it takes to do set theory, then go up from there etc. it's turtles all the way down. In practice land (real theorem provers), I guess the idea is that, it theoretically should be a perfect logic engine. Two issues: 1. What if there's a compiler bug? 2. How do I "know" that I actually compiled "what I meant" to this logic engine? (which are re-statements of what I said in theory land). You are given, that supposedly, within your internal logic engine, you have a proof, and you want to translate it to a "universal" one. I guess the idea is, in practice, you just hope that slight perturbations to either your mental model, the translation, or even the compiler itself, just "hard fail". Just hope it's a very not-continuous space and violating boundaries fail the self-consistency check. (As opposed to, for example, physical engineering, which generally doesn't allow hard failure and has a bunch of controls and guards in mind, and it's very much a continuuum). A trivial example is how easy it is to just typo a constant or a variable name in a normal programming language, and the program still compiles fine (this is why we have tests!). The idea is, that, down from trivial errors like that, all the way up to fundamental misconceptions and such, you can catch preturbations to the ideal, I guess, be they small or large. I think what makes one of these theorem provers minimally good, is that you can't easily, accidentally encode a concept wrong (from high level model A to low level theorem proving model B), for a variety of reasons. Then of course, runtime efficiency, ergonomics etc. come later. Of course, this brings into notion just how "powerful" certain models bring - my friend is doing a research project with these, something as simple as "proving a dfs works to solve a problem" is apparently horrible.
• bobbylarrybobby 1y ago
  Let's prove it. 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.
  • jph00 1y ago
    The author does not say a script works as well as a proof.
  • vatsachakrvthy 1y ago
    If you want to be lazier, after finding the generating functions one can plug into sympy to skip the algebra.
• deleted 1y ago
  [deleted]
• veganjay 1y ago
  Reminds me of an old calculator trick: 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
• _def 1y ago
  > The exact ratio is not 14, but it’s as close to 14 as a standard floating point number can be. How do you get around limitations like that in science?
  • gus_massa 1y ago
    You can use Mathematica or Sage that can use any number of digits https://www.wolframalpha.com/input?i=FEDCBA987654321_16+%2F+123456789ABCDEF_16+-14 https://www.wolframalpha.com/input?i=FEDCBA987654321_16+%2F+... You can use special libraries for floating point that uses more mantisa. In most sciences, numbers are never integers anyway, so you have errors intervals in the numerator and denumerator and you get an error interval for the result.
  • deleted 1y ago
    [deleted]
  • necovek 1y ago
    You can do symbolic calculations carrying precisely defined numbers (eg. PI, 3/7...), you can use tools which allow arbitrary precision (it's only slower by several orders of magnitude so not too bad if you don't need millions of calculations: this includes Python if you use Decimal objects), or you can use error calculus to decide if the final error is acceptable.
  • sltkr 1y ago
    For rational numbers, Python has a Fraction class in the standard library that performs exact integer arithmetic: >>> from fractions import Fraction >>> f = Fraction(0xFEDCBA987654321, 0x123456789ABCDEF) >>> f%1 Fraction(1, 5465701947765793) >>> f - f%1 Fraction(14, 1) That shows that 0xFEDCBA987654321 / 0x123456789ABCDEF = 14 + 1/5465701947765793 exactly. >>> math.log(5465701947765793, 2) 52.279328213174445 Shows that the denominator requires 52 bits which is slightly more than the number of mantissa bits in a 64-bit floating point number, so the result gets rounded to 14.0 due to limited precision.
• lutusp 1y ago
  > I recently saw someone post [1] that 987654321/123456789 is very nearly 8, specifically 8.0000000729. Okay. Try this (in a Python terminal session): >>> 111111111 ** 2 12345678987654321 (typo corrected)
• gus_massa 1y ago
  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 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.)
  • debtta 1y ago
    An easier way to evaluate sum i/10^i is by squaring sum 1/10^i If you multiply term by term every term has coefficient 1 of course. There are n terms with exponent n+1, made from the n sums of the first exponent and the second exponent. Eg 1+5, 2+4, 3+3, 4+2, 5+1. So (1/9)^2 = (sum 1/10^i)^2 = 1/10 sum i/10^i The derivative trick is more useful generally, but this method gets you the solution to 0.12345678.. in an quick way that's also easier to justify that it works.
• deleted 1y ago
  [deleted]
• jamesmaniscalco 1y ago
  This is fun! but not so surprising to me: 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.
• uticus 1y ago
  this reminds me of the online encyclopedia of integer sequences (https://oeis.org/ https://oeis.org/). anything similar for things like 987654321 / 123456789 ?
  • uticus 1y ago
    ...followup after looking through comments on OP, indeed someone else already had the idea to tie in OEIS sequences in the comment at https://www.johndcook.com/blog/2025/10/26/987654321/#comment-1191863 https://www.johndcook.com/blog/2025/10/26/987654321/#comment... but i still wonder if there is something like OEIS for observations / analysis like this
    • madcaptenor 1y ago
      That was me. The best I know is to find a related sequence and look it up in the OEIS.
• nomilk 1y ago
  TIL 0x denotes hexadecimal E.g. > 0xFEDCBA987654321 / 0x123456789ABCDEF (somehow I'd seen the denotation for years yet never actually known what it was).
  • extraduder_ire 1y ago
    Numbers with a leading 0 are octal (base 8) in many programming languages too.
• notorandit 1y ago
  May I Say 355/113 ?
• kazinator 1y ago
  Here is a correction which m akes it exactly 8.0: > 987654320 / 123456790 8.0 I've decremented the numerator and incremented the denominator: ( 987654321 - 1 ) ----------------- = 8 ( 123456789 + 1 ) Works in other bases. TXR Lisp, base 4: 1> (/ (poly 4 '(3 2 1)) (poly 4 '(1 2 3))) 2.11111111111111 2> (/ (poly 4 '(3 2 0)) (poly 4 '(1 2 4))) 2.0 It also works for base 2, which is below the lowest base used in the article: the Python code goes from 3. For base 2, the ratio is 1/1. When we apply the correction, we get (1 - 1) / (1 + 1) = 0, which is 2 - 2.
• jojobas 1y ago
  12345679 (oh no, we forgot the 8!) - let's multiply by 8 = 98765432.
• hamonrye 1y ago
  [dead]
• scriptweaver 1y ago
  Math can be so fun when you find patterns like this, it’s like hidden magic in numbers.
• usr1106 1y ago
  Sounds interesting, but site is behind the great Cloudflare firewall. Cannot see it on this phone.
• adrian_b 1y ago
  As a young child, a half of century ago, when I have received an electronic pocket calculator (with 8-digit numbers and without transcendental functions) I was taught that I can do a quick check whether it functions correctly by multiplying 12345679 with 8 (using thus all non-null digits), when the result must be 98765432. Obviously, an additional check is the corresponding division that reverses this operation.
  • gowld 1y ago
    Did you ever encounter a dysfunctional calculator? That test wouldn't detect a dead left side on the 2nd from-right digit
    • adrian_b 1y ago
      Obviously, that was not intended to be a full-functionality test, but it would detect any frequently-encountered display defect (or keyboard defect). Calculator displays are multiplexed, so the usual defects are either one digit that never displays anything, or one segment that stays blank on all digits. The defect mentioned by you is frequent only on displays with independent digits (like some digital clocks), not on calculators. I do not know whether on calculator LCD displays there are frequent cases when a single segment can become defect. At the time about which I am talking, calculators had either green vacuum fluorescent displays (like mine) or red LED displays. With such displays, the normal defects were either in the driving circuits or in the connections to the multiplexed display, so they affected either all segments of a digit or the same segment in all digits. I have never seen a case when the actual light-emitting segment of a digit of a VFD or LED display was defect.
• qnleigh 1y ago
  > Why include a script rather than a proof? One reason is that the proof is straight-forward but tedious and the script is compact. Yes the script lets you check that the result is correct, but a proof lets you see why it's correct. A good proof might even give you a sense of how you could have discovered the result yourself, or how you might generalize it.
• CoderLim110 1y ago
  The beauty of mathematics, imperfection is also a kind of beauty.