The submitted paper is well-written and appears to be correct, but it is far too short.
No reference is made to previous attempts to study Euler's conjecture or similar conjectures (there are surely a dozen other papers that ought to be cited in the introduction).
What led the authors to consider a computer search as opposed to any other approach? Does the method generalize?
It is indicated that the CDC 6600 was used. How was the programming done? How long time did the execution take? The instance is claimed to be "the smallest". In what norm? How can you be sure that the computer program did not skip any smaller examples?
The most serious problem with the paper, however, is that the only contribution is a purely computational statement which, though a counterexample to a conjecture, does not advance mathematical theory in any way.
Due to these shortcomings, my recommendation to the editor is to REJECT the submission.
for anyone wondering, the parent is 100% sarcasm and making fun of editors. (The REJECT is the punchline).
You can tell by "How can you be sure that the computer program did not skip any smaller examples?"
However, in actuality it really is actually too short. For example, it would be far more interesting to us in 2016 to read this early computational result if it included "reference made to previous attempts to study Euler's conjecture or similar conjectures", also "What led the authors to consider a computer search as opposed to any other approach?" and so forth.
Also in 2016 it would be extremely interesting to know "How was the programming done? How long time did the execution take?" For purely history-of-computation reasons.
Also it would be really interesting for the authors to have listed their own views on the ramifications, i.e. in what way it advances mathematical theory (or not).
Even though the parent comment is sarcastic, as a reader in 2016, I got next to nothing out of the paper. If it had been rejected on the above (sarcastic) basis, and the authors had submitted a six-page version, it would be far more interesting to us. The same would have been true for contemporaries.
> though a counterexample to a conjecture, does not advance mathematical theory in any way.
[I realize it's sarcasm but in case it's not clear to everyone, I'll speak my mind about it]
I think it's a pretty serious advancement. Confirming a conjecture is just as important as invalidating it with a counter example. It doesn't matter if that counter example fits on one line.
Maybe my mind is warped, but I actually agree with that. The conjecture isn't the point. There are plenty of interesting counterexamples, but a direct search does nothing to advance mathematics.
> No reference is made to previous attempts to study Euler's conjecture or similar conjectures
Why should this be even necessary? There are surveys for that. Not every mathematician needs to be a historian. Nor do most people like to read the same introduction in every paper on a certain topic.
While I acknowledge the humor intended, it is important to note that nipping incorrect conjectures before people waste time building edifices atop them, is an extremely good outcome. In the strongest possible manner, this advances mathematics by labeling incorrect pathways as being incorrect.
You only need one counterexample to a theory or conjecture to prove it wrong.
This is great from so many angles. The counterexample is solid mathematics, the paper is wonderfully to the point, and the use of computers to successfully investigate a pure math problem was innovative.
I only wish they'd described the method they used to find the counterexample.
As a first attempt, I guess you'd create a table of 5th powers of integers through (say) 1000, then look for combinations of two, three, or four entries from the same array that added up to one of the same numbers. Or more likely, walk through the array and subtract all combinations of one, two, three, or four elements from each, looking for zeroes. The most naive search through such a table could take on the order of a trillion trials to find a counterexample, which is pretty painful, but I'm sure there are plenty of ways to optimize it. Especially if you worked from high to low, you could skip enormous chunks of the search space that would take the computation out of range.
The CDC 6600 was a pretty hardcore machine; it was Seymour Cray's first design at his Chippewa Falls skunk works, according to Wikipedia. Would definitely be interesting to know how long their solution took.
You don't have to store S4, so 2 megabytes of memory or so should suffice. 10^11 operations likely was out of reach for the CDC600, though.
To speed up things, do the above for numbers up to 100 or so using modulo arithmetic. That gives you candidate solutions modulo your word size. That way, you don't have to compute large parts of S4.
I computed an array of fifth powers, up to 200, then had four nested loops. Using python3 on a 2.66-GHz Core 2 Duo, it took 48 seconds to find the reported numbers. If there had been no solutions, it would have taken only a couple of seconds longer.
That's modern hardware, where recomputing n^5 + m^5 when needed may on average be faster than doing the lookup with its risk of a cache miss.
That CDC6600 dates from a time where register access wasn't much faster (if it was faster at all. https://en.m.wikipedia.org/wiki/CDC_6600#Description: For instance, a processor might take 15 cycles to multiply two numbers, while each memory access took only one or two) than reading from memory, and integer multiplication took >1 cycle (https://en.m.wikipedia.org/wiki/CDC_6600#Description: in addition to the clock being faster, the simple processor executed instructions in fewer clock cycles; for instance, the CPU could complete a multiplication in ten cycles.)
I've actually written FORTRAN on a CDC 6600, at Dalhousie University. The algorithm was probably written in assembler (COMPASS) for speed. The 6600 had a 60-bit register, advanced for its time. The cabinets had some real cool glass panels. The console was two futuristic vector CRTs.
There's a more detailed discussion at "A Survey of Equal Sums and Power" by L. J. Lander, T. R. Parkin and J. L. Selfridge http://www.jstor.org/stable/2003249 (under 5.1.n)
One could probably start with the fact that the last 2 digits of any 5th power are in "0, 1, 7, 24, 25, 32, 43, 49, 51, 57, 68, 75, 76, 93, 99" and go from there.
Is it known what the smallest power is for which three summands are insufficient? Is there a smallest power? I imagine that would be hugely difficult, but for all I know it falls to the same methods as Fermat. (I'm no expert.)
Edit: I guess the answer might be "5" depending on what the paper means by "smallest" example. (smallest largest number vs smallest smallest number.)
A fine example of the fact that brute force is often a powerful heuristic. I believe I recall hearing from the MIT OCW Algorithms course that they often rely on computer time doing exhaustive search (i.e. brute force) to "not disprove" some algorithm they develop before sinking too much time into developing a mathematical proof.
I think "exhaustive search" is a misnomer here, as one obviously cannot exhaustively search the integers. (Unless we might say the machine gets exhausted.)
I believe this is the quote you're referring to, by Erik Demaine on 6.006:
"I use BFS a lot, myself, to check mathematical conjectures. [...] You think something is true, you can imagine some graph of all possible inputs to that theorem and you'd need to check them. Typical way of doing that is BFS through that entire graph of states. Usually we're testing finite special cases of a general conjecture, but if we find a counterexample, we're done, don't have to work on it anymore. If we don't find a counterexample then we have to do the mathematics."
No reference is made to previous attempts to study Euler's conjecture or similar conjectures (there are surely a dozen other papers that ought to be cited in the introduction).
What led the authors to consider a computer search as opposed to any other approach? Does the method generalize?
It is indicated that the CDC 6600 was used. How was the programming done? How long time did the execution take? The instance is claimed to be "the smallest". In what norm? How can you be sure that the computer program did not skip any smaller examples?
The most serious problem with the paper, however, is that the only contribution is a purely computational statement which, though a counterexample to a conjecture, does not advance mathematical theory in any way.
Due to these shortcomings, my recommendation to the editor is to REJECT the submission.