Motivation
Currently, the caller always chooses the solver explicitly: BruteForce::new().find_best(problem). This works but doesn't let individual problems declare a preferred or specialized solver. As the solver ecosystem grows (BruteForce, ILP, and future specialized solvers like BDD-based reliability or DP-based subset counting), it would be convenient for each problem to specify a default solving strategy.
Proposal
Add a DefaultSolver mechanism where each problem can declare its preferred solver:
trait HasDefaultSolver: Problem {
fn solve_default(&self) -> SolveResult;
}The default solver could delegate to:
- BruteForce — for most problems (the baseline)
- ILP solver — for problems with known efficient ILP formulations
- Custom solvers — e.g., BDD-based exact computation for NetworkReliability, pseudo-polynomial DP for KthLargestSubset
This applies uniformly to all three problem kinds (optimization, satisfaction, counting).
Trade-offs
Pros:
- Convenient single entry point:
problem.solve_default()
- Each problem can choose the best known algorithm
- Future specialized solvers integrate naturally
Cons:
- Couples problem definition with solver choice (current separation is clean)
- For most problems today, BruteForce is the only available solver
- Return type needs to be unified or generic across optimization/satisfaction/counting
Status
Future architecture idea. Filed during the CountingProblem design discussion. Orthogonal to the counting trait work — benefits all problem kinds equally.
Related: #737 (generalized metric aggregation)
Motivation
Currently, the caller always chooses the solver explicitly:
BruteForce::new().find_best(problem). This works but doesn't let individual problems declare a preferred or specialized solver. As the solver ecosystem grows (BruteForce, ILP, and future specialized solvers like BDD-based reliability or DP-based subset counting), it would be convenient for each problem to specify a default solving strategy.Proposal
Add a
DefaultSolvermechanism where each problem can declare its preferred solver:The default solver could delegate to:
This applies uniformly to all three problem kinds (optimization, satisfaction, counting).
Trade-offs
Pros:
problem.solve_default()Cons:
Status
Future architecture idea. Filed during the
CountingProblemdesign discussion. Orthogonal to the counting trait work — benefits all problem kinds equally.Related: #737 (generalized metric aggregation)