Repository navigation
Heaviest-term lower bound on C_g over generator states - #60
Merged
Merged
Conversation
…nerator states heaviest_term_bound takes a weight_cap per box; generator_heaviest_term_bound supplies the one-explicit-state generator-cap LP. Opt-in pipeline stage (generator_heaviest_term=True). Co-authored-by: Cursor <cursoragent@cursor.com>
3 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Ports the cpfci prototype
gen_heaviest_bb.py, the first bound to certifyC_g > Gon a survey process with a full-support joint.heaviest_term_boundtakes an optionalweight_cap(box): an extra upper bound on the heavy term's weight over a box, orNoneto prune it. Without it the static bound is unchanged.generator_heaviest_term_bound(problem, ...): a generator's states are an exact decomposition whose heaviest term is its heaviest state, and that state satisfies the generator equations, so the weight cap is the one-explicit-state generator-cap LP (_HeaviestStatesRelaxation(problem, 1)) over the box of beliefs. The docstring records why the root's weight floor1/(2^m - 1)(a cardinality bound on optimal decompositions) stays valid for generators with more states: a lighter heaviest state forcesH[pi] >= log2(2^m - 1) >= min(C_mu+, C_mu-) >= C_g.generator_heaviest_term=Falseby default; when set, it runs after the static stage on joints with|S+| + |S-| <= 7while the bracket is open, with a 0.3 share of the remaining budget.Why opt-in
On
((0,1),(0,2),(0,1))the LP excludes theG-optimal heavy term only in boxes of radius about1e-4, so the bound passesG = 0.92433after ~220k boxes (about 30 min) and plateaus at 0.928157 after 8 h. On RLL it stays atGfor 40 s. Inside a default time budget it would rarely help.Test plan
((0,1),(0,2),(0,1))(matrices embedded): the LP admits theG-optimal heavy term (t* = 0.6944) in a radius-1e-2box and caps it belowt* - 1e-3at radius1e-4ruff;tyhas no new diagnosticsMade with Cursor