golden_vs_tempered_probe RUN — T1-T4 all PASS, two real defects caught by actually running it - #935
Conversation
…d BEFORE the run Independent, committed reproduction of the hand-derived T1-T4 numbers in golden-vs-tempered-stride-v1.md. If a number disagrees with the plan's table, the plan's table is corrected -- this script is the source of truth going forward. Zero fetch, deterministic, no RNG. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
…o real defects caught in the hand-derived numbers Ran the committed probe against the pre-registered bars. All four bars PASS (T2 asymptotic advantage true at all 10 q; T3 tempered closure proven exact; T4 39.0% naive-rounding collapse rate matches the hand-derived figure exactly). Two real methodology defects were caught by actually running the script rather than trusting the scratch-derived plan numbers: 1. T1's m* (crossover point) was computed inconsistently with the plan's own prose in the original draft. The draft recomputed the TEMPERED sequence's discrepancy at each growing m>q -- but a tempered walk past m=q is REPEATING its own q positions, feeding duplicate points into a formula built for distinct order statistics, which spuriously WORSENS instead of staying frozen. Worked example, q=17: at m=18 (where the stride's 18th sample lands exactly back on the 1st) the repeating-sequence recomputation jumps to 0.1111 -- worse than the true frozen 0.0588 -- making golden's 0.0832 look like a win when it is still worse than tempered's real ceiling. Fixed: hold tempered at its true frozen m=q value (matching the plan's own "repeats identically forever" definition). Every corrected m* is >= the draft's value; the qualitative claim survives but "sits almost exactly at m~=q" is corrected to "within roughly 1.0-1.4x of q". 2. T3's original method checked BOTH walks via a float round-trip (k/q then *q then int()), and for the TEMPERED walk (a proven exact bijection by coprimality) this produced a false negative: 138/140 filled instead of 140/140, from pure IEEE-754 truncation (int(46.99999999999999) rounds down to 46). The mathematical fact was never wrong; the measurement code was. Fixed: verify the tempered bijection via pure integer arithmetic ((s*i) mod q, no float round-trip at all), which cannot have this artifact -- confirmed 140/140 always. The golden check (float, inherently continuous) is unaffected and stays legitimate. Removed the completed run's .partial.jsonl checkpoint (no other probe in this repo retains one after clean completion; the stranded-rescue protocol has no purpose once a run finishes in under 5 seconds). Plan updated in place with the corrected numbers, both correction notes inline, and the RUN status throughout. Nothing here weakens the head-vs-gut synthesis; it tightens two specific numbers and demonstrates, twice, why "commit the bars then run" catches things "commit the bars and trust the scratch math" does not. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_101177e4-5111-4968-9117-600d0cc6d910) |
|
Warning Review limit reached
Next review available in: 14 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
… BEFORE the run Golden two-lattice pairing on real cos-lat lat/lon geometry vs an axis-aligned grid control, per weather-w-probes-v1.md SS2 (N=F(17)^2 headline + the G4 index-floor sweep). Committed exactly as specified in the brief before execution. Smoke-tested at N=50k first (caught nothing wrong in the code -- but surfaced a real, mechanically-understood geometric property worth flagging before the full run: two IDENTICALLY-SPACED regular grids offset by a pure translation vector are, by lattice symmetry, translation-invariant in their cross-nearest-neighbour distance -- every point of one grid sees the exact same local neighbour configuration in the other, so CV(nearest-pair distance) is near machine-epsilon regardless of the offset (verified: 4 different offsets from 0 to 300km all gave CV ~1e-12 to 1e-13). This may make G2 fail against its pre-registered expectation for a real, structural reason rather than a code defect -- reported honestly either way once the full run completes, not redesigned mid-flight to force the expected answer. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5d4ea5226d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for m in range(q, 20 * q + 1): | ||
| if star_discrepancy(golden_pts(m)) < temp_frozen: | ||
| m_star = m | ||
| break |
There was a problem hiding this comment.
This loop stops at the first transient dip below the tempered threshold, although m_star is documented and reported as the point where golden stays below it permanently. For example, at q=17 it records m*=21, but the golden discrepancy rises to about 0.08137 at m=22, above the frozen tempered value 1/17 ≈ 0.05882; similar reversals occur for every published row. Consequently, the headline m*/q = 1.0–1.4 crossover and the associated synthesis are based on first crossings rather than permanent crossings.
Useful? React with 👍 / 👎.
| dominate a naive worst-case-over-all-m metric into near-uselessness. | ||
| Returns (score, stride). | ||
| """ | ||
| lo = max(2, q // 2) |
There was a problem hiding this comment.
For every odd q, q // 2 includes one prefix below the preregistered range m ∈ [ceil(q/2), q], so the committed table does not reproduce its stated method. At q=17, for example, including m=8 reports tempered/golden median scores 0.10420/0.11686, while the specified start at m=9 gives approximately 0.09664/0.10872. Use (q + 1) // 2 (and the same bound for the golden score) so the published measurements match the bar.
Useful? React with 👍 / 👎.
…ctually permanent) Both real, both caught by codex on the RUN result of golden_vs_tempered_probe.py: 1. (P2) useful_range_lo used q//2 (floor) where the documented range is [ceil(q/2), q]. For every odd q this admits one prefix below the stated floor -- q=17: q//2=8 vs ceil(17/2)=9. Fixed with a single ceiling-division helper (useful_range_lo) that best_coprime_stride and t1_crossover both call, so the two computations can never drift apart again. 2. (P1, the substantive one) m* was a FIRST-crossing search, not a verified PERMANENT one, despite being reported and used throughout the plan as "the point golden permanently overtakes". Golden's raw discrepancy sequence is not monotonic -- only its O(log m/m) envelope is a bound -- so a single dip below the tempered ceiling can be followed by a rise back above it. Codex's exact example reproduced: q=17 reported m*=21, but D*(22)=0.08137 > the frozen ceiling 0.05882 -- not permanent at all. Replaced with verified_permanent_crossover: on finding a candidate crossing, verify it holds at a SAMPLED checkpoint set (every integer for the next 50 steps -- catches exactly this near-term-reversal failure mode -- plus ~15%-geometrically-spaced points out to the m=200q horizon, plus the horizon itself); on any checkpoint violation, restart the scan past it. The checkpoint COUNT is reported alongside every m* so the verification scope is never silently overclaimed as exhaustive. For q=17, the verified m* is 32, not 21 -- reran and confirmed before this commit. Both fixes land in the committed script before rerunning, per the standing discipline (bars/methodology committed, then run, never the other way). Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
…run with verified-permanent m* + E-A-CONTROL-THAT-CANNOT-LOSE-IS-NO-CONTROL-1 High-signal epiphany first (operator directive): the falsifiability rule's can-it-fire doctrine applies to CONTROL ARMS with the same force as to guards -- a control that cannot lose by construction carries zero information when it wins. Two independent instances in one afternoon: 1. W2s-a's grid control: two IDENTICALLY constructed grids differing only by a pure translation are, by lattice symmetry, translation-invariant in their cross-nearest-neighbour distance -- CV ~1.6e-12 vs golden's 0.368, twelve orders of magnitude, invariant under 4 different center offsets. The control cannot lose ANY evenness comparison against ANY irregular construction. Diagnosed via a 0.1s smoke test at N=50k BEFORE the full 2.55M run; run as-specified anyway (deliberately -- the record shows the specified control failing, not a quiet redesign forcing the expected answer). G2/G4 verdicts: FAIL, with the diagnosis attached. G1: VOID via its own pre-registered escape hatch (grid also 0 ties). G4 honesty note: 3 near-ties in 3.15M golden points at n=19 (ABOVE the floor) -- the fixed 1e-6 relative tolerance admits ~1e-6-rate coincidences at large N; the pre-registered "stays exactly 0" was overclaimed for large N. 2. golden-vs-tempered T1's m* (codex P1 on #935): first-crossing search reported as "permanent" -- an implicit never-reverses control that was never checked. q=17: m*=21 claimed, D*(22)=0.081 back above the 0.059 ceiling. Fixed with verified_permanent_crossover (sampled suffix: every integer for 50 steps + geometric checkpoints to 200q, count REPORTED beside every m* so scope is stated not implied). Also fixed the codex P2 off-by-one (q//2 -> ceil(q/2), single shared helper). Verified m* moved from ~1.0-1.4x q to ~1.9-2.7x q -- the number's third revision, each widening: golden needs ~two tempered cycles before its lead is durable, and its eventual dominance (68-106x at 200q, T2, never exposed to either bug) is unchanged. Plan updates in place (both plans carry full correction trails, three-stage for m*); STATUS_BOARD rows D-W2sA + D-GVT-T1 updated; probe JSONs regenerated; partial checkpoints cleaned after successful completion. The synthesis survives all four corrections in direction and weakens in no cell; what moved is tightness -- and the honest crossover is now: tempered holds its ground for roughly TWO of its own cycles, not one. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
The previous commit's message claimed "STATUS_BOARD rows D-W2sA + D-GVT-T1 updated" -- only D-W2sA had actually been edited; D-GVT-T1 still carried the first-crossing 1.0-1.4x range that codex P1 falsified. Caught by verifying the commit message's own claims against the tree immediately after pushing (the #930-arc lesson: prose and patch are written in the same breath and only the patch is checked by anything). Row now carries the verified-permanent 1.9-2.7x figure with both codex fixes named. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
…e run Full post-#933 brief: N=3*F(17)^2=7,651,227 headline, bump at r0=0.75 (local index ~2077 > floor 1597), KD-tree stride discovery with no capped window, band qualification by the INNER-radius >= r_floor rule (bands 4-8; the brief's "bands 3-8" label is off-by-one against its own parenthetical r>=0.6124 -- the rule wins, discrepancy reported not silently adopted), distance-matched shuffled-neighbour B3 control (same 0.25/0.5/0.25 stencil both arms; control prev = reverse map where uniquely defined, else hold -- documented implementation choice), B4 sweep n in {8,10,12,14,17,19} at 3*F(n)^2 each, n=21 recorded NOT RUN per budget. Smoke-tested at n_idx=8 (N=1323, machinery-only, sub-floor by design): discovery correctly returns the F(8)/F(9)=21/34 pair, both arms run, JSON shape complete. The smoke run's poor isotropy at that N is exactly the sub-floor behaviour B4 exists to expose and is not a code defect. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
#935: the validation wave's run record (T2/T3/T4 PASS, T1 twice-corrected to verified-permanent m* = 1.9-2.7x q, W2s-a G1 VOID / G2-G4 FAIL with the degenerate-control diagnosis, the new epiphany, the in-flight W5 note). #934: written one PR late -- it merged and the operator's "run tests to validate" directive rightly took priority; the omission was caught in this hygiene pass and the entry says so rather than backdating. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
Ran the just-merged golden-vs-tempered-stride-v1 plan
Per the standing discipline: committed the probe script with its bars first (
38c56d00), then ran it. All four bars PASS. Running it caught two real defects in the hand-derived plan numbers — both explained inline, both fixed in the committed script, neither weakens the synthesis.Results
round(golden·q)Two real defects the run caught
m*was computed inconsistently with the plan's own prose. The draft recomputed the tempered sequence's discrepancy at each growing m>q — but a tempered walk past m=q is repeating its own q positions, feeding duplicates into a formula built for distinct order statistics, which spuriously worsens instead of staying frozen. Worked example at q=17: at m=18 (where the 18th sample lands back on the 1st) the repeating-sequence recomputation jumps to 0.1111 — worse than the true frozen value 0.0588 — making golden's 0.0832 look like a win when it's still worse than tempered's real ceiling. Fixed: hold tempered at its true frozen m=q value, matching the plan's own "repeats identically forever" definition. Every corrected m* is ≥ the draft's; "sits almost exactly at m≈q" is corrected to "within roughly 1.0–1.4× of q".k/qthen*qthenint()) reported only 138/140 filled for tempered atoff=0.0— pure IEEE-754 truncation (int(46.99999999999999)rounds down to 46). The mathematical fact (coprimality ⇒ exact bijection) was never wrong; the measurement code was. Fixed: verify via pure integer arithmetic ((s·i) mod q, no float round-trip), which cannot have this artifact.Removed the completed run's
.partial.jsonlcheckpoint on cleanup — no other probe in this repo retains one after a clean sub-5-second completion; the stranded-rescue protocol exists for runs that could die mid-flight, not this one.Board:
STATUS_BOARD.mdD-GVT-T1..T4 moved Queued → RUN with one-line results.Doc/plan/board + one committed probe script + its JSON result — zero product code.
🤖 Generated with Claude Code
https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
Generated by Claude Code