Does lcm(n+1, …, n+k) ever repeat later on? — k=2, k=3, k=4 all closed
The target (erdosproblems.com/677). M(n,k) = lcm(n+1, n+2, …, n+k). Does M(n,k) ever equal M(m,k) for m ≥ n+k? Our own brute-force search this morning (k=2..11, n<4,000) found zero collisions — a real signal, not a guess. Here's what came back.
k=2 — closed, trivially. M(n,2) = lcm(n+1,n+2) = (n+1)(n+2), since consecutive integers share no factors. Strictly increasing. Never repeats, full stop. Confirmed directly.
k=3 — fully classified. The only pair with M(n,3) = M(m,3), n < m, in existence is (n,m) = (2,3): lcm(3,4,5) = lcm(4,5,6) = 60. Everything else, forever, is distinct. We didn't take the algebra on faith — we independently brute-forced every n up to 200,000 and found exactly that one collision and no others, which is strong empirical confirmation the classification is complete. (Under the hood, the proof routes through a genuine cubic unit equation in ℤ[∛2] — real algebraic number theory we didn't re-derive by hand, but the conclusion it produces matches our search exactly.) Note (2,3) doesn't violate the original question anyway — it's an overlapping pair (m=3 < n+k=5), not a counterexample to the disjoint case actually asked.
The boundary case, for every k. A genuinely new piece: is M(n,k) = M(n+k,k) — the tightest possible disjoint pair — ever possible? Proven no, for every k ≥ 2, via a clean prime-gap argument (Sylvester–Schur for large starting points, Nagura's theorem for the rest, one finite case checked by hand). We independently verified this holds with zero violations across k=2..29, n up to 2,000.
What's still open: general k with a gap bigger than the boundary (m > n+k). That's the actual remaining content of #677. One honest process note: Erdős's original 1979 statement used the strict inequality m > n+k — our brief's inclusion of the boundary case m = n+k was an extension beyond what he originally asked, which is exactly why proving it impossible is a real (if narrow) addition, not just a restatement.
Round 2 — k=4 fully closed. The only collision anywhere is (n,m)=(1,2): lcm(2,3,4,5)=lcm(3,4,5,6)=60, again overlapping, not a counterexample. The proof is a genuine Cohn–Kedlaya-style Pell certificate — reduce to V²−3U²=−2, track a specific residue class of the solution sequence through a finite congruence cover (three primes, mod 8 and mod 48), then use quadratic reciprocity to eliminate every remaining case. This time we didn't just check the conclusion — we ran the actual certificate script ourselves, verifying the primality of all three primes, the full congruence cover, and the reciprocity computation, completely independently. Every assertion passed. We also independently re-derived the underlying Pell algebra by hand (exact arithmetic in ℤ[√3]) and confirmed a real classical cross-check: a 1975 paper (Ponnudurai, J. London Math. Soc.) proves the broader unrestricted equation has exactly two positive solutions — the one we found, plus one more that fails our problem's extra congruence condition (we confirmed that failure directly too). Two independent methods, same answer.
A real negative result, just as valuable. We also now know why the diagonal/routing framework that worked for the boundary case can't close general k on its own — an explicit construction (large primes placed via CRT) satisfies every transport constraint without being a real collision. Closing all k needs a genuinely different ingredient: a joint "consecutive-integers" realization condition on both windows at once, not just prime-power routing.
Where k=5 and k=6 actually stand: not equally hard. k=5 reduces to seven genus-6 curves — real, hard arithmetic geometry. k=6 reduces to just four elliptic curves — a much more tractable next target. Counterintuitively, k=6 before k=5 is the right order.
Round 3 — k=6 pushed hard, honestly not closed. The overlapping case (windows that share terms) is now completely classified: exactly three collisions exist anywhere, full stop — (n,m)=(3,4), (5,6), (13,15). We didn't take that on faith — an independent brute-force search out to n=2000 found the identical three, nothing else. The disjoint case reduces to an integral point search on four explicit elliptic curves, and we verified every piece of that reduction ourselves: the valuation bookkeeping that forces the ratio between two windows into {2, 5/2, 5, 10}, the compression identity that turns a degree-6 product into a genuine cubic, and — the sharpest check — a "trap" the brief itself flagged: some integer points on these curves are real points but NOT real window pairs (they fail a square-coordinate test). We verified two such decoy points directly, and verified the three genuine ones map back to exactly the three known collisions. Nothing here overclaims: the brief explicitly declined to "dress up" a rank computation as a proof, because the four curves need a harder, non-routine certified integral-point method (elliptic logarithms + a Mordell–Weil sieve, not just computing ranks) — real literature on exactly this shape of problem, confirmed to exist. k=6 stays open, but the actual remaining computation is now fully specified, down to the code that would run it.
The bigger payoff: what "joint realization" actually is. The earlier negative result showed prime-routing alone can't close general k. This round names the real replacement: a family of curves built the same way for every k, whose genus climbs with k in a precise, checkable pattern — a conic for k=4, an elliptic curve for k=6, genus 3 for k=8, genus 6 for k=10 (matching the seven genus-6 curves already found for k=5). The honest diagnosis of what's actually missing: not a congruence condition, but a uniform way to control these curves' Selmer data across every k at once — real arithmetic geometry, not a shortcut waiting to be found.