I spent way longer than I care to admit slapping together a Java program to chew through the first thousand or so. Here's the log output -- some get really damned close, but nothing exact (or within 16 decimal digit precision) yet.
Edit: re-running with an upper bound of 10,000 now. This will probably take a couple of hours since it's running a triple-nested loop without any duplicate checks.
Edit 2:
Found on Google+ by John Baez
https://plus.google.com/+johncbaez999
Don't try this puzzle
It looks childish, but this puzzle is sadistically difficult. Saying that 95% of people can't solve this is like saying 95% of people can't jump over a skyscraper.
Here is the simplest solution:
apple = 154476802108746166441951315019919837485664325669565431700026634898253202035277999
Cool, so using my current method all I need to get the solution is, uh, a million trillion trillion trillion trillion exabytes of RAM... per particle in the universe.
You can implement a sieve. I found that all 3 numbers have to be different and that you can assume that they don't share a common factor (also obviously you can assume that x<y<z so you don't have to recheck every one of the permutations), so you can skip these numbers for starters, and then you can figure out more restrictions.
It can definitely be optimized, but the point is that brute force isn't a viable option in the first place. Maybe with something GPU-based where you can stream a ludicrous number of simultaneous calculations, but I don't know if that will let you get into 80+ digit (roughly 67+ bit) values with exact precision. OpenCL caps out at 64-bit for integers, or at least used to:
(Edit: I don't know. I haven't worked with OpenCL. Me enterprise monkey. It sounds like you'd have to implement your own equivalent to BigDecimal/BigInteger around the GPU registers, which starts adding a lot of overhead for packing and unpacking your parameter triad values.)
...and then there's the problem of calculating exact-precision intermediate results. There's a reason the NSA pissed dump trucks full of money into PRISM.
I spent way longer than I care to admit slapping together a Java program to chew through the first thousand or so. Here's the log output -- some get really damned close, but nothing exact (or within 16 decimal digit precision) yet.
spoiler
[INFO ] 2021-03-18 01:37:24.187 [main] Main - Beginning formula tester run. [INFO ] 2021-03-18 01:37:24.582 [main] FormulaTester - Found near match with error value of +/- 0.0000004298293256: 2, 264, 993 [INFO ] 2021-03-18 01:37:24.794 [main] FormulaTester - Found near match with error value of +/- 0.0000004298293256: 2, 993, 264 [INFO ] 2021-03-18 01:37:31.815 [main] FormulaTester - Found near match with error value of +/- 0.0000000953396933: 35, 132, 627 [INFO ] 2021-03-18 01:37:31.916 [main] FormulaTester - Found near match with error value of +/- 0.0000000953396933: 35, 627, 132 [INFO ] 2021-03-18 01:37:45.415 [main] FormulaTester - Found near match with error value of +/- 0.0000006695134379: 101, 133, 881 [INFO ] 2021-03-18 01:37:45.569 [main] FormulaTester - Found near match with error value of +/- 0.0000006695134379: 101, 881, 133 [INFO ] 2021-03-18 01:37:51.774 [main] FormulaTester - Found near match with error value of +/- 0.0000000953396933: 132, 35, 627 [INFO ] 2021-03-18 01:37:51.896 [main] FormulaTester - Found near match with error value of +/- 0.0000000953396933: 132, 627, 35 [INFO ] 2021-03-18 01:37:51.996 [main] FormulaTester - Found near match with error value of +/- 0.0000006695134379: 133, 101, 881 [INFO ] 2021-03-18 01:37:52.157 [main] FormulaTester - Found near match with error value of +/- 0.0000006695134379: 133, 881, 101 [INFO ] 2021-03-18 01:38:19.067 [main] FormulaTester - Found near match with error value of +/- 0.0000004298293256: 264, 2, 993 [INFO ] 2021-03-18 01:38:19.274 [main] FormulaTester - Found near match with error value of +/- 0.0000004298293256: 264, 993, 2 [INFO ] 2021-03-18 01:39:34.405 [main] FormulaTester - Found near match with error value of +/- 0.0000000953396933: 627, 35, 132 [INFO ] 2021-03-18 01:39:34.426 [main] FormulaTester - Found near match with error value of +/- 0.0000000953396933: 627, 132, 35 [INFO ] 2021-03-18 01:40:26.750 [main] FormulaTester - Found near match with error value of +/- 0.0000006695134379: 881, 101, 133 [INFO ] 2021-03-18 01:40:26.757 [main] FormulaTester - Found near match with error value of +/- 0.0000006695134379: 881, 133, 101 [INFO ] 2021-03-18 01:40:51.955 [main] FormulaTester - Found near match with error value of +/- 0.0000004298293256: 993, 2, 264 [INFO ] 2021-03-18 01:40:52.016 [main] FormulaTester - Found near match with error value of +/- 0.0000004298293256: 993, 264, 2 [INFO ] 2021-03-18 01:40:53.853 [main] FormulaTester - No valid solutions found for range 0 to 1000. [INFO ] 2021-03-18 01:40:53.853 [main] Main - Formula tester run complete.Edit: re-running with an upper bound of 10,000 now. This will probably take a couple of hours since it's running a triple-nested loop without any duplicate checks.
Edit 2:
...I think it is going to be running for a while.
Cool, so using my current method all I need to get the solution is, uh, a million trillion trillion trillion trillion exabytes of RAM... per particle in the universe.
You can implement a sieve. I found that all 3 numbers have to be different and that you can assume that they don't share a common factor (also obviously you can assume that x<y<z so you don't have to recheck every one of the permutations), so you can skip these numbers for starters, and then you can figure out more restrictions.
It can definitely be optimized, but the point is that brute force isn't a viable option in the first place. Maybe with something GPU-based where you can stream a ludicrous number of simultaneous calculations, but I don't know if that will let you get into 80+ digit (roughly 67+ bit) values with exact precision. OpenCL caps out at 64-bit for integers, or at least used to:
https://stackoverflow.com/questions/6366996/work-with-128bit-or-256bit-unsigned-integers-in-opencl
(Edit: I don't know. I haven't worked with OpenCL. Me enterprise monkey. It sounds like you'd have to implement your own equivalent to BigDecimal/BigInteger around the GPU registers, which starts adding a lot of overhead for packing and unpacking your parameter triad values.)
...and then there's the problem of calculating exact-precision intermediate results. There's a reason the NSA pissed dump trucks full of money into PRISM.
Yeah idk... I've found a bunch of restrictions but it's still pretty huge...
Oh, I forgot some more restrictions: the largest number has to be smaller than 4 times the sum of the other two, but larger than 2.5 times their sum.