Skip to content

Path ranking: Pareto layers over target parameters (symbolic and numerical modes) #1179

Description

@isPANN

Summary

Add path ranking to pred path (and the matching library and MCP API). Ranking only reorders and annotates the candidates; the user still chooses one explicitly with pred reduce --via. This brings back path selection, which #1137 removed on purpose (MinimizeSteps, Minimize(field), CustomCost). The design below avoids the problems of that version: a "cheapest path" search whose cost doesn't only grow along a path, and a single cost number when sizes are not comparable.

Two modes

Symbolic mode (pred path MIS/i64 QUBO/i64): only the source and target variants are given, with no instance and no parameter values. Each path's composed parameter transform is a formula in the source parameters, so paths are compared as formulas:

  • Project each target field's formula with Growth::from_expr and compare with Growth::dominates (src/growth.rs).
  • Output Pareto layers: layer 1 = paths no other path beats, layer 2 = paths beaten only by layer 1, and so on. Comparing over the target's whole parameter vector means no weighting is needed.
  • Some paths are incomparable because of missing information: an unavailable field, a Turing step, or O(?). These go into a separate unrankable group that shows the reason.
  • Tie-breaks inside a layer: exact before upper bound, then fewer hops, then the existing canonical order.

Numerical mode (pred path MIS QUBO mis.json): run each path on the instance (#1177, with budget #1178) and measure the actual target parameters. All values are exact u64, so rank with the same Pareto layers. Failed and over-budget paths are reported separately. The symbolic Growth is shown next to each measured path, because a ranking measured on one instance doesn't carry over to other instances.

Objective

  • Default: Pareto over the full target parameter vector.
  • Optional --objective "<expr over target parameters>", parsed with Expr::parse, allowing any combination of target fields. It must be monotone, i.e. never decrease as a parameter grows; Growth already assumes and checks this. Reject it otherwise.
  • Target complexity strings are too weak to be the default: QUBO's is O(2^num_vars), which ignores num_quadratic_terms; ILP/i64 is O(?); 85 of 256 variants have O(?).

Candidate generation

Candidates currently come from Yen's k-shortest paths by hop count. Many of them are variant-only detours: 25% of 1,190 sampled candidate paths contain two or more steps that only change the variant (for example MIS SimpleGraph → TriangularSubgraph → UnitDiskGraph → SimpleGraph), and 9% leave a problem and later come back to it. For LCS → ILP, 13 of the top 20 are such detours, and they use up the --limit slots.

  • Remove variant round trips before ranking, or don't generate them.
  • Say in the output that ranking covers only the first k paths by hop count. A longer path with smaller growth may be missing, just as truncation is reported today.

Related display bug

Without an instance, the ReductionPath summary line merges consecutive steps with the same problem name. The result is Path (6 steps): MIS → MaxClique → ILP → QUBO, which looks identical to the 4-step path. Output with an instance doesn't merge them, so the two outputs are also inconsistent.

Dependencies

Tasks

  • Library: a score for each path, symbolic (Growth per field) or measured, plus Pareto layering with deterministic tie-breaks.
  • CLI/MCP: show layers and the unrankable group in text and JSON; add --objective.
  • Update docs/src/design.md, which currently says Growth "does not rank or filter paths".
  • Tests: dominance, incomparable pairs, unrankable reasons, deterministic ordering.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DiscussionNeed some human feedback and expert validation.enhancementNew feature or request

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions