These knobs govern the integer cut/cube heuristics (the "hammers":
find_cube, lcube, hnf, gomory, dio), not just cuts, so the names now
reflect that. lp.int_hammer_period sets the shared firing period and
lp.random_hammers toggles random vs deterministic gating.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The toggle also gates the cube heuristics (find_cube, lcube), not just
cuts, so 'cut' in the name was misleading. random_period covers all the
periodic integer heuristic gates (find_cube, lcube, hnf, gomory, dio).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Rename the toggle so it sits beside lp.cut_period and reads as a
modifier on it (cut_period + random) rather than burying "cut" in the
middle of the name.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Introduce the boolean lp.random_cut_period parameter (default true).
When enabled, the periodic integer heuristic gates (find_cube, lcube,
hnf, gomory, dio) fire at random with the same 1/period expected rate;
when disabled they fall back to the deterministic every-k-th-call
modulus on m_number_of_calls. The shared hit_period() helper centralizes
this decision, and m_number_of_calls is restored for the deterministic
path.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The find_cube, hnf and gomory integer heuristics were all throttled by a
hardcoded period of 4 (m_int_find_cube_period, m_hnf_cut_period,
m_int_gomory_cut_period). Make this value tunable through the new
lp.cut_period parameter (default 4, preserving current behavior) so the
period can be swept (e.g. 3/4/5) for benchmarking. A value of 0 is clamped
to 1.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Implemented the largest cube heuristic from Bromberger and Weidenbach's
paper on cubes. Also fixes an overflow bug in mzp.
Use vswhere to find the visual studio version on windows in the build's ymls.
---------
Signed-off-by: Lev Nachmanson <levnach@hotmail.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
#7791 reports on using model values during lex optimization that break soft constraints.
This is an artifact of using optimization where optimal values can be arbitrarily close to a rational.
In a way it is by design, but we give the user now an option to control the starting point for epsilon when converting infinitesimals into rationals.
there are some different sources for the performance regression illustrated by the example. The mitigations will be enabled separately:
- m_bv_to_propagate is too expensive
- lp_bound_propagator misses equalities in two different ways:
- it resets row checks after backtracking even though they could still propagate
- it misses equalities for fixed rows when the fixed constant value does not correspond to a fixed variable.
FYI @levnach
