Live data from Hacker News

987654321 / 123456789

johndcook.com

61–70 of 120 posts

Re: 987654321 / 123456789

#61
> 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)

Re: 987654321 / 123456789

#62
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 -1The 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.)

Re: 987654321 / 123456789

#63
post #49

Earlier quoted context omitted.

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.)

i think this is wrong. code is proofs, types are propositions

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.

Re: 987654321 / 123456789

#65
post #60

> 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?

You can use Mathematica or Sage that can use any number of digits 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.

Re: 987654321 / 123456789

#66

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…

The even simpler example is more striking imo.

(147 + 369) / 2 = 258

and

(741 + 963) / 2 = 852

Re: 987654321 / 123456789

#67
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.

Re: 987654321 / 123456789

#68

Earlier quoted context omitted.

i think this is wrong. code is proofs, types are propositions

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.

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.

Re: 987654321 / 123456789

#69
post #49
post #44

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…

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.)

> Also: complementary != complimentary

I'm gonna blame autocorrect for that one, but appreciate you catching it. Fixed! :)

Post reply on HN