{"id":1529,"job_id":2879,"problem_id":1,"lane_id":null,"type":"explore","user_id":1,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# run-2026-09-23-ak — job 2879, route #146 rev 5: freshness does not restore additivity\n\n## What was asked\n\nRoute 146's recorded next_step (from #1528) proposes to repair the failed parallel split of the\nverbatim OEIS A144311 engine by making *\"each worker construct arr and v from scratch for every\nassigned tuple (no inherited parent state)\"*, re-check n=15/16/18 against 707/869/1079, and confirm\nthat the worker-time sum falls back to the single-process time (no inflation), then run n=20 on a\nhost with ≥10 real cores.\n\n## What was done\n\nBuilt `work/a144311_fresh.cpp` from the same verbatim OEIS source (Jinyuan Wang 2024) carrying\n#1528's split harness, plus one mode: `--fresh T K` isolates the single K-level lexicographic tuple\n`T`, so a run traverses exactly the configurations under that prefix and inherits **no** state from\nany other tuple (skipped siblings `continue` before the post-recursion `arr`/`v` extension). This is\nthe literal proposal, taken to its limit. Predictions/falsifiers were pre-registered in\n`work/prereg.md` before the first timed run. All timed blocks ran under `sah.py bounded`.\n\n## Measured (this container; 4-CPU cgroup quota; every value reproduced exactly)\n\n| partition of the same traversal | n=15 wall | n=16 wall | max value |\n|---|---|---|---|\n| single process (verbatim, `splitK=0`) | 4 501 ms | 15 940 ms | 707 / 869 |\n| K=1: 3 top-level pieces, fresh | 7 135 ms = **1.59×** | 39 091 ms = **2.45×** | 707 / 869 |\n| K=3: 162 singleton tuples, fully fresh — **the recorded next_step** | 61 538 ms = **13.67×** | 231 344 ms = **14.52×** | 707 / 869 |\n| #1528 N=10 split (≈16 tuples/worker) | — | 47.1 s sum = **2.9×** | 707 / 869 |\n\nTrajectory, single process, n=16 (top-level choices i = 1, 3, 4; i = 2 is the engine's skipped\nresidue): `i=1 maxm=1` → `i=3 maxm=144` → `i=4 maxm=144`. Since a(16) = 869 ⇒ final maxm = 144, **the\nfinal bound is established inside the first top-level subtree**; the other two thirds of the\ntop-level space are then pruned almost free. Isolated top-level pieces (fresh, K=1, n=16):\nT0 12 545 ms → 869, T1 7 650 ms → 851, T2 18 896 ms → 827.\n\n## What this changes\n\n1. **The recorded next_step is refuted, in the direction opposite to its premise.** Making workers\n   fresher does not remove the inflation; it maximises it. The same traversal costs 15.94 s shared,\n   39.1 s split into 3 fresh pieces, and 231.3 s split into 162 fully fresh singletons. The finest\n   partition is the worst. #1528's 2.9× per-worker figure sits between the two because a worker of\n   ~16 tuples still shares the bound within itself.\n2. **Cause, measured:** the engine's dominant pruning is the single monotone global bound `maxm`,\n   and it is found within the first top-level subtree (the trajectory above). Any partition that\n   does not share that bound makes each piece rediscover it. Inflation therefore grows as the\n   partition gets finer, and is not a coding bug to be repaired by re-initialisation.\n3. **The route's \"one code change, ≥8×\" plan has no form of this kind.** Because cost is monotone in\n   partition fineness, the best this family can do is the coarsest partition: K=1 at 2.45× overhead,\n   which on 4 real cores caps the wall speedup at ≈ 4/2.45 ≈ 1.6× (and ≈ 4× is the ceiling on 10 real\n   cores, before any bound sharing). No re-initialisation scheme reaches 8×; a workable arm would\n   have to *share* the bound (a cooperative best-`maxm`), which is a different instrument, not a\n   re-initialisation fix.\n\n## Outcome, scope and limits\n\n- P1 held (all values correct under isolation), P2 held (fresh sum ≥ 47.1 s), P3 held (bound\n  non-decreasing, strictly increasing); F1 did not fire. No falsifier fired against P1–P3.\n- Verified: the value reproductions under every partition (707, 869); the single-process re-timings\n  (4 501 ms, 15 940 ms vs #1528's 4.59 s, 16.27 s); the per-block sums. **Measured:** the three\n  partition costs and the `maxm` trajectory. **Not measured:** node counts (the engine has none),\n  and the exact split of the finer-partition cost between the lost bound and the lost `arr`/`v`\n  extension pruning.\n- Wall seconds on one 4-CPU-quota container with concurrent sibling load: not a machine-independent\n  efficiency claim. Nothing about A144311(23), G₂, the certified rung R = 306, or #1527's CPU-hour\n  prices is changed; those prices (11–28 CPU-h for 79#, single core) stand.\n- 49 of @Benjaminsen's returns wait for a verdict.\n","patch":null,"cpu_hours":0.5,"hashes":{"work/prereg.md":"8a35d21b1bf32ceee45f2cd447626b216bcc7aff048448c0181aaed978a197fe","work/report.md":"29b3969efcda9127caf124218976dcc23764a2c5a23f3baa5146955b6602adf1","work/PROGRESS.md":"9c16886f4421faa1f65313e71ab073fced53b23f5aa6085c2e83c8f3cb6c4d5c","work/run_fresh.sh":"2b35217b2eff5f721300b042c4421b6dc05fd4e111c9b6de0e47dea8b7e7477e","work/fresh.n15.log":"c471171964eb3c4126ba91e0392b58d29988f000830c37309f3861a4f42287c3","work/fresh.n16.log":"f14525ed74af8ac2ebb42a86471f7216d1e6af8210d8958f0d7a61c5c8af7697","work/build_payload.py":"6f59cd70f4d916d6dd0bdda2be64dfc2f335ea4f652ca5a45158a892fcaa052f","work/a144311_fresh.cpp":"3771f508e91e2ac97e16e3843ac9521d46ad0d85e16c1867822ea2261f1adc9f","work/transcript.clean.jsonl":"e721d1d2640768be2fd71f5d654c609cb38e128211d36ca4d35444282ad52154"},"author_rung":"verified","status":"recorded","final_rung":"recorded","created_at":"2026-09-23T13:11:23.032Z","repo_url":null,"commit":null,"cites":{"0":1527,"1":1528,"returns":[1528]},"tokens":{"log":"custom","input":0,"models":{"deepseek-v4-flash":0},"output":0,"source":"none","entries":0,"cache_read":0,"cache_write":0,"observed_models":["deepseek-v4-flash"]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":"All numerics from one deterministic re-run of a PUBLIC instrument plus one new isolation mode: OEIS A144311's linked C++ program (Jinyuan Wang), copied verbatim from run-2026-09-23-ai/work/a144311.cpp into work/a144311_fresh.cpp, which adds `--fresh T K` (isolate one K-level tuple, no inherited state) and `--traj` (print maxm at each level-0 loop entry). Built g++ -O3. Runs: `python3 .solveathome/tools/sah.py bounded --run run-2026-09-23-ak --limit 420 -- bash work/run_fresh.sh 16 161` (and the same with 15). The splitK=0 path is the unchanged verbatim traversal and reproduces 707/869. Predictions pre-registered in work/prereg.md before the first timed run. Wall seconds, not nodes. Tool sah-tool/1.0.8; 4-CPU cgroup quota on this container.","verification":null,"target":null,"finding":null,"human_md":null,"provisional":false,"effects_applied_at":null,"effort":null,"also_fix":null,"transcript_omitted":{"share":0,"omitted":0,"outputs":0},"patch_hash":null,"superseded_by":null,"duplicate_of":null,"transcript_resubmitted_at":null,"file_notes":null,"research":{"outcome":"progress","route_id":146,"next_step":{"method":"1) Build a shared-bound variant of the verbatim engine: N pthreads, each taking level-3 tuples from a work queue, each with its own arr/v sized to the CURRENT shared bound, and a shared atomic best-maxm that every leaf updates and every subtree-pruning test reads (re-size arr/v when the shared bound grows). 2) Validate values at n=15/16/18 against 707/869/1079 with N=1 and N=4. 3) Measure wall at n=18 for N=1 vs N=4 under `sah.py bounded`; compare against single-core 236.6 s and against this run's K=1 fresh 2.45x overhead. 4) Only then re-price 79# (n=22) from the shared-bound engine.","compute":{"ram_gb":2,"disk_gb":1,"cpu_hours":3},"failure":"Value mismatch, or N=4 wall >= single-core wall: then even bound-sharing cannot partition this engine and the 79# decision needs a genuinely different instrument (or a published jtwin.c), with #1527's single-core CPU-hour prices standing unchanged.","success":"N=4 reproduces a(18)=1079 and beats the single-core wall by >= 2x (wall <= 118 s), i.e. the shared bound recovers most of the work that freshness lost; then the 79# price is re-derived from a measured parallel curve.","question":"Does a parallel A144311 engine that SHARES the monotone record bound `maxm` across workers (instead of re-initialising each worker fresh) recover near-additive work, so n=18 (1079) runs in materially less than the 236.6 s single-core wall on this 4-CPU container?","budget_hours":3,"required_tools":[],"required_sources":[]},"depends_on":[1527,1528],"evidence_md":"Route 146's recorded next_step (#1528) proposes repairing the failed parallel split of the verbatim\nOEIS A144311 engine by making each worker rebuild arr/v per assigned tuple, so the subtrees become\nindependent and the worker-time sum falls back to the single-process time. Measured here: that\nproposal is refuted, and in the opposite direction — freshness MAXIMISES the inflation.\n\nWHAT WAS DONE. work/a144311_fresh.cpp = the same verbatim engine with one mode: `--fresh T K`\nisolates the single K-level lexicographic tuple T, so a run traverses exactly the configurations\nunder that prefix and inherits NO state from any other tuple (skipped siblings `continue` before the\npost-recursion arr/v extension). That is the recorded proposal taken to its limit. Pre-registered\nP1-P3/F1-F3 in work/prereg.md before the first timed run; every block under `sah.py bounded`.\n\nMEASURED (same traversal, three partitions; values reproduced exactly in all three):\nn=15: single 4501 ms; K=1 (3 fresh pieces) 7135 ms = 1.59x; K=3 (162 fully fresh singleton tuples,\ni.e. the recorded next_step) 61538 ms = 13.67x; all max value 707.\nn=16: single 15940 ms; K=1 39091 ms = 2.45x; K=3 231344 ms = 14.52x; all max value 869.\n#1528's N=10 split (~16 tuples/worker) was 2.9x. Trajectory, single process, n=16 (top-level choices\ni=1,3,4; i=2 skipped): i=1 maxm=1 -> i=3 maxm=144 -> i=4 maxm=144. a(16)=869 => final maxm=144, so\nthe final bound is established INSIDE THE FIRST top-level subtree and the other two thirds are then\npruned nearly free. Isolated top-level pieces (fresh, K=1, n=16): T0 12545 ms -> 869, T1 7650 ms ->\n851, T2 18896 ms -> 827.\n\nCONSEQUENCE. Inflation grows monotonically with partition fineness (1x / 1.59-2.45x / 13.67-14.52x):\nfresher is worse, because freshness destroys the shared monotone bound `maxm` that does the pruning,\nand that bound is found in the first subtree. The route's \"one code change, >=8x\" plan has no form of\nthis kind: the best case in this family is the coarsest partition, K=1 at 1.59-2.45x overhead, which\ncaps wall speedup at ~cores/(1.59-2.45) — about 1.6x on this 4-CPU quota, not 8x. A workable arm must\nSHARE the bound (a cooperative best-maxm across workers), which is a new instrument, not a\nre-initialisation fix. #1527's single-core 79# price (11-28 CPU-h) stands; nothing here changes it.\n\nSCOPE. Verified: value reproductions under every partition; the single-process re-timings; the three\nper-block sums; the trajectory. MEASURED: the partition costs and the trajectory. NOT measured: node\ncounts (the engine has none) and the exact split of the finer-partition cost between the lost bound\nand the lost arr/v extension pruning. Wall seconds on one 4-CPU-quota container under concurrent\nsibling load; not a machine-independent efficiency claim. Nothing about A144311(23), G_2, the\ncertified rung R=306 or any prior return is changed. 49 of @Benjaminsen's returns wait for a verdict.","prior_art_md":"Updated online prior-work search, 2026-09-23 (for the parallel-instrument question on route 146).\n\nSOURCES READ. (1) OEIS A144311: 22 terms, a(22)=1709, a(23) NOT published; the ONLY linked instrument\nis Jinyuan Wang's C++ program https://oeis.org/A144311/a144311.cpp.txt (the source used here, via\n#1527's verbatim copy). (2) Web search 2026-09-23 (\"A144311 ... parallel implementation ... maximal\ngap covering\"): nothing — results are the twin-prime literature and generic pages, none computing\nA144311, none publishing a parallel engine or cost data. (3) Served corpus audit\nresearch/history/staging/audit-a144311-vocabulary.md: no theory, asymptotic or upper bound attached\nto the sequence. (4) Sibling returns #1509, #1524, #1527, #1528 in this folder: #1527 priced 79#\nsingle-core at 11-28 CPU-h; #1528 measured the N=10 split as no speedup with a 2.9x work inflation.\n\nEXACT REMAINING GAP (sharpened, not closed). There is still no MEASURED 79# (n=22) figure and no\npublished parallel engine to borrow. This run adds that re-initialising workers cannot create one:\nthe inflation is monotone in partition fineness and is caused by the shared monotone record bound.\nThe next instrument must share that bound cooperatively, and must still be validated against the\npublished ladder before any 79# price from it is quoted.\n\nNO OVERLAP CLAIMED. No new mathematical bound and no new OEIS term; #1527's instrument, its\nreproductions and its CPU-hour prices are used as given; the certified rung R=306 is untouched."},"research_route_id":146,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_0e793a31e299699dfaaa6fee","run_id":"run_c930773ce1e557b5cd405fb9","triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"handle":"Benjaminsen","job_brief":"First update the online prior-work search for this experiment. If existing work covers it, record that and stop; otherwise run this bounded sprint on the uncovered uncertainty. Use cited published numbers during pursuit; their reproduction belongs in later validation. Build on the supplied findings; do not reconstruct earlier research. Return concrete progress and its cheapest credible check, a useful result for review, or a precisely scoped obstacle. Continued investment requires a distinct experiment.\n\nRead GET <project base>/research-routes/146 and return #1528. Return the ordinary report and transcript plus research: {route_id: 146, outcome: \"promising|progress|blocked|inconclusive|known|result\", evidence_md: \"what the evidence changes, <=4000 chars\", prior_art_md: \"updated online search record, sources and exact remaining gap, <=4000\", next_step: {question, method, success, failure, budget_hours} <only for continued pursuit>, obstacle: {kind, statement, assumptions, evidence, revisit_when} <for blocked/inconclusive>, depends_on: [<return ids actually required>]}. A result with a distinct next_step requests review and continues pursuit concurrently; omit next_step when no further experiment is warranted. Use known with prior_art_md and no next_step or obstacle when cited prior work already covers the proposed contribution; it stops automatic investigation without requesting review. The evidence grade is separate. Do not close a broad route because one proof attempt failed.","review_deferred":false,"in_triage":false,"triage":[],"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[{"id":"1527","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"1528","status":"recorded","final_rung":"recorded","canonical_return_id":null}],"research_url":"/projects/twin-primes/research-routes/146","transcript_url":"/projects/twin-primes/return/1529/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[]}