/machines/1RB0RB_0LC0RA_1LE1LD_0LE---_1LF0LC_1RA1LB/notes.md · raw

1RB0RB_0LC0RA_1LE1LD_0LE---_1LF0LC_1RA1LB

Label: H-1 (halting hunt). 740 list line 686. Class: Bell eats counter (our class claim; this machine got its own claims line on 2026-10-13).

Family: this is 347's table (1RB1RF_1RC0RA_1LD1RE_1LE0LE_0RA0LD_0RB---, ours, STUCK "cryptid-margin suspect"), relabeled and mirrored (347 A,B,C,D,E,F -> 686 C,E,F,A,B,D). 441 is the same table from another start. A 686 phase start

0^inf rev(W) (01)^M <C 0^inf        (C reads the last 1)

is 347's 0^inf A> (10)^M W 0^inf. So 347's rules, invariant G1 and margin analysis apply verbatim (347 notes.md, rounds 1-3).

Halting comes only from margin breaks. A break is k_align(W) > M-1, where k_align is the number of Incs until the counter is aligned.

Halting hunt: exact model (2026-10-13)

Result: no halt to phase 127,822,269 (M = 2,055,209,149; about 3.5e26 steps). No margin break.

The model

Scripts are in scripts/.

fastmap.py is 347's validated fast phase map (deepen3_fast.phase) with one more exact acceleration, for the Incs before alignment: - Write the counter as P X. P is the longest prefix of wide aligned frames (d in 1..3, even width >= 4). X is the rest, the "head". - While some digit of P is below 3, an Inc changes only P, as bijective base 3 with fixed widths. This is 347's Inc rule (1300/1300), the same one deepen3_fast.add already applies to aligned counters. - So the Incs until P is all 3s are added arithmetically. - The single Inc that carries out of P into X runs at cell level (deepen2_orbit.bounce_ctr, bell reduced to 3 blocks). It is a Gap-Inc, a J-rule sub-phase, or a d3/T overflow. - X does not change during prefix Incs, so the result is Inc-for-Inc identical to while not aligned(c) and k < M-1: c = bounce_ctr(c). - The marker walk is still deepen2_orbit.crossing, at cell level.

Cost per phase is O(cell-level carries + crossing), independent of M:

implementation time per phase
old map (t347fam.py), M = 1.5e5 0.3 s
fastmap.py (Python) 2 ms
fastmap.c (C) 45 us

Other scripts: - fastmap.c is a C port with the same semantics; binaries fastmap686 and fastmap686d are both builds of it. The long run used a build from before the --dump option was added, which gives identical P and C lines on 15,000 phases. - run686.py is the Python driver. - Model phase starts map to 686's real configurations through the mirror map above.

Validation

check result
Python map vs the old map (fam686.txt): M, k_align and len(W), phases 304..15,303 15,000/15,000
C map vs fam686.txt 15,000/15,000; full counters equal Python's at all 32 checkpoints
C vs Python, phases 15,304..90,000 9/9 checkpoints (M and full counter); identical X line and histogram
C vs Python, forward from C checkpoints M equal at 6 far phases (31,857..821,496)
C map on 347's own orbit (deepen3_orbit_ext.txt, phases 1,323..11,798, written by the old code) 10,476/10,476 phase starts; 10,475/10,475 k_align
Direct, continuous: 686 itself (tools/sim C core), chained phase by phase from the direct start 304 (step 999,091,126 of the run from the blank tape) 1,300/1,300 phases (304..1,604; M 2,313 -> 13,516; 1.84e11 steps). Includes phase 725 (0.73) and the 0.9755 near-miss, phase 1572. Steps per phase = 2M²·(1.0008..1.0088)
Direct, one whole phase: phase 31,857 (ratio 0.9071, M = 330,841) ok: 218,919,745,095 steps -> M' = 330,891 and W' equal to the model's
Direct component checks at full bell size (dcheck686.c on 686's own table: every cell-level carry, 4-10 random arithmetic Incs as the counter after k vs k+1 Incs, and the crossing, each on 686's real tape with the full bell; compcheck686.py) 286/286 items ok over 13 phases, M from 3.3e5 to 1.19e9: phases 31,857; 38,295; 102,646; 289,482; 803,608; 821,496; 1e6; 5e6; 1e7; 2e7; 4e7; 43,355,647 (the 0.9893 near-miss, M = 6.6e8); and 7.5e7 (M = 1.19e9). Also 17/17 on a forced-break phase (below)
Mutation check of dcheck686 14/14 corrupted expectations (a flipped counter cell, or a wrong M') flagged

A shifted Inc index is not flagged, which is correct: the result does not depend on the bell position.

The run

> 0.1 > 0.2 > 0.3 > 0.4 > 0.5 > 0.6 > 0.7 > 0.8 > 0.9 >= 1
23,937 8,950 67 23 8 8 8 3 2 0

Every phase above 0.5 on the whole orbit (q = floor(log3 M)):

phase M k_align ratio M/3^q k/3^q
725 5,853 4,293 0.7336 2.676 1.963
1,572 13,204 12,879 0.9755 2.012 1.963
31,857 330,841 300,105 0.9071 1.868 1.694
38,295 405,709 308,367 0.7601 2.290 1.741
102,646 1,156,546 890,655 0.7701 2.176 1.676
289,482 3,467,681 2,657,231 0.7663 2.175 1.667
289,972 3,474,132 2,676,215 0.7703 2.179 1.679
803,608 10,192,162 9,039,111 0.8869 2.131 1.890
821,496 10,436,128 8,013,087 0.7678 2.182 1.675
43,355,647 662,347,287 655,286,211 0.9893 1.710 1.691

Max ratio per window q (M in [3^q, 3^(q+1))):

q 7 8 9 10 11 12 13 14 15 16 17 18 19 (to M/3^q = 1.77)
max ratio 0.734 0.976 0.424 0.423 0.907 0.770 0.770 0.887 0.425 0.426 0.427 0.989 0.311

What the margin looks like (new)

k_align is a sum of carry costs. - Each chain head needs two cell-level carries: a Gap-Inc merge (o2), then a J-rule sub-phase. - A carry with an aligned prefix of q frames costs r+1 Incs, where r is the prefix's distance to all-3s. That is 3^q - 1 when all digits are 1, the state chain resolution leaves. - Examples: - Phase 31,857: carries at prefix lengths 5, 5, 7, 8, 10, 10 and 11, giving k_align = 300,105. - Phase 1572: k = 12,879 = 3^8 + 2·(3^7 + 3^6 + 3^5).

Empirical bound. Over every phase, k_align/3^q <= 1.963 (q = floor(log3 M)). Unlogged phases have ratio <= 0.2, so k/3^q < 0.6 there. So the ratio is below 1.963·3^q/M <= 1.963. - The nearly full chains (k/3^q > 1.5) are only 10 phases so far, and all have M/3^q >= 1.71. - A break needs k/3^q > M/3^q: a nearly full chain while M is less than about 1.96·3^q.

How deep a break has to be to halt (new, scripts/forcebreak.py). - Method: take the 3,169 orbit phase starts with ratio > 0.2 from phases 15,304..1.5e7 (fastmap686d --dump 0.2 -> work/c_dump.txt). Force each bell down to M = f·k_align and run 3 exact phases.

f 0.95 0.75 0.70 0.65 0.60 0.56 0.53 0.51 0.50 0.33 0.20 0.10 0.03
halts / 3169 0 0 0 91 261 311 140 208 170 824 753 944 820

A forced halt reproduced on 686 itself at scale (W5-5 style; work/forced_halt_*): 1. Start: orbit phase 10,562,630 (M = 151,485,246, k_align = 41,977,788), with its bell forced to 20,988,894 (f = 0.5). 2. The broken phase was checked directly: 17/17 components on 686 at full bell. 3. The model says the next phase (M = 20,988,895) halts at the carry after k = 4,865 Incs. 4. Running 686 from the configuration reproduce686.py builds just before that carry halts after 41,968,189 steps (D reads 1). 5. So the model's halts are real halts of the machine at M ~ 2e7, and the certification path (model -> configuration just before the halt -> tools/sim) works.

Consequence for the hunt. - A halt on the orbit needs a break of depth about 1.5 or more. That means k/3^q >= 1.5·M/3^q, so a nearly full chain (k/3^q up to 1.96) while M/3^q <= 1.3. - In 127,822,269 phases, nearly full chains appeared only at M/3^q >= 1.71. So the deepest "break" seen is 0.989, against the roughly 1.5 a halt needs. - The yield estimate is lower than the ranking's. Even a mild break (ratio 1-1.43) would not halt. The ranking's "mild break every 1e6-1e7 phases" did not happen either: 0 breaks in 127.8 million new phases.

Possible proof lead (not a result). Non-halting would follow from two lemmas: 1. k_align < 2·3^floor(log3 M) together with a coupling between chain depth and M/3^q that keeps the ratio below about 1.4. 2. Breaks of depth below 1.43 recover. This is supported by the forced tests: 0 of 9,507.

This is the margin lemma that 347's round 3 could not find, restated in log3 terms. It would cover 347, 441 and 686 together.

Outcome and what is left