Mirror of forum.nim-lang.org

4714 :: [some offtopic] 33 = (8866128975287528)^3+(-8778405442862239)^3+(-2736111468807040)^3

• oyster (orginal) [2019-03-13T13:19:47+01:00] view original

  Recently, I read that it is the first time that human finds 3 integers x, y and z which make x^3+y^3+z^3=33, where the finding is (8866128975287528)^3+(-8778405442862239)^3+(-2736111468807040)^3 in this March 2019. Till March 2019, we still can't find x, y and z for some numbers, for example, 42, 114, 165, 390, 579

  Firstly I think we can make a three-variant-for-loop to find the answer. But obviously it is not a good solution. Maybe GPU can do better than CPU.

  Then I think some rules may be used: the end number of x^3 can be used to judge. But the if-else maybe takes more time then for-loop

  So, do you have any idea?

---

• Libman (orginal) [2019-03-14T01:09:08+01:00] view original

  To state the obvious... This isn't Nim related, but serious computation challenges typically require:

  • Looking for the most efficient search algorithm. This is for math PhDs, which I definitely am not.
  • The ideal algorithm would also be easy to map to many simultaneous processes. For example, Computer A might check [0,3,6..], Computer B [1,4,7..], and Computer C [2,5,8..]. There are sophisticated control programs for slicing out the jobs, since the number of available computers can change over time.
  • These computations usually involve expensive supercomputers / networks of thousands of computers, which is very expensive. Unless you have a major research grant, you probably won't be very competitive.
  • With so much hardware and electricity cost involved, math researchers are incentivized to spend a lot of time fine-tuning their algorithms and implementations. Nim is a great programming language for most tasks, and it has gmp bindings / etc, but it wasn't meant to compete with hand-optimized C or assembly language.

---

• Araq (orginal) [2019-03-14T01:35:06+01:00] view original

  but it wasn't meant to compete with hand-optimized C / Fortran / Assembly language.

  Sure it was. By design C-like Nim code has no overhead.

---

• Libman (orginal) [2019-03-14T04:21:49+01:00] view original

  I wanted to play around with Nim GMP for a much simpler experiment: seeing how long it would take to find a clong.rand array that SO3C to <2 billion, which is billions of times easier than hitting a specific number. Turns out: quite a while... 🙄

  ---

  but it wasn't meant to compete with hand-optimized C / Fortran / Assembly language.

  Sure it was. By design C-like Nim code has no overhead.

  I should have just said "hand-optimized Assembly language"...

---

• andrea (orginal) [2019-03-14T09:54:45+01:00] view original

  Well, in any case a trivial implementation will have no chance to succeed whatsoever, Nim, C or Assembly. If you want to replicate the result, you should at the very least use the methods described in the paper https://people.maths.bris.ac.uk/~maarb/papers/cubesv1.pdf Even then, consider the following quote from the paper:

  The total computation used approximately 15 core-years over three weeks of real time.

  :-)

---