Iteration 5
RetrieveGate decision
RetrieveReasoningAdditional evidence would help because the current search documents are largely conceptual or generic Qiskit references and prior experiments have plateaued or regressed. Fresh exploration should target…
Additional evidence would help because the current search documents are largely conceptual or generic Qiskit references and prior experiments have plateaued or regressed. Fresh exploration should target repository-specific routing context APIs and concrete implementations of depth-aware, critical-path, or other candidate-ranking heuristics beyond the already tried relative distance deltas and greedy layout variants.
Knowledge before this stepThe strongest measured result is combined_score 6957.0 from the relative distance-delta scoring combined with component-aware initial layout. Attempt 3's more elaborate layout placement reduced the score to 6565.8, so…
The strongest measured result is combined_score 6957.0 from the relative distance-delta scoring combined with component-aware initial layout. Attempt 3's more elaborate layout placement reduced the score to 6565.8, so that change should not be retained. Existing documents establish the SABRE/LightSABRE principles, especially normalized front/lookahead costs, relative candidate scoring, decay, depth, and critical-path heuristics. However, they do not provide repository-specific Rust APIs for depth or critical-path state, nor do they identify a reliably beneficial alternative for this benchmark. The unresolved opportunity is therefore a new routing or layout heuristic that can improve swap/CNOT outcomes without the expensive or harmful behavior seen in prior attempts.
Population analysis
📊 State: The retained population contains 5 programs with scores ranging from 6387.0 to 6957.0, and the current parent is tied for the best score at 6957.0.
Key Numbers:
• Score distribution: mean 6673.0, median 6565.8, and population standard deviation 238.84.
• Score spread: the best score is 6957.0 and the worst is 6387.0, a 570.0-point range.
• Score uniqueness: 4 unique scores occur across 5 programs, with 2 programs tied at 6957.0.
• Trajectory: retained scores rose from 6387.0 at iteration 0 to 6957.0 at iteration 4; iterations 1–3 were marked improved, while iteration 4 was not_improved globally.
Patterns Observed:
• Parent selection: 4 programs had parent selections across 4 selection slots, using 2 unique parent IDs; the most-selected parent was used 2 times, representing 50% of parent selections.
• Context selection: 2 programs had context selections across 2 slots, using 2 unique context IDs; the most-selected context represented 50% of context selections with 1 selection.
• Outcomes: the retained child gains were 111.0, 67.8, 570.0, and 459.0 points; the largest gain produced a score of 6957.0 from a parent score of 6387.0.
Query · round 1
"SABRE" adaptive lookahead decay swap scoring weighted interaction frequency initial layout Rust GitHub
Find a practical adaptive SABRE heuristic or interaction-frequency-based layout method that improves on fixed front-layer/lookahead weights and greedy component placement without requiring unavailable depth or critical-path APIs.
Query rationale
The current program already achieves its best score with relative distance deltas, decay, and component-aware layout, while the attempted elaborate placement was harmful. Existing searches established LightSABRE concepts but not usable Rust APIs. This query targets a lower-cost, implementable alternative: dynamically weighting front-layer versus extended-set costs or using temporally weighted logical interactions to refine initial placement and swap choices.
What this round establishedThe current relative front-layer and normalized lookahead scoring remains the strongest measured configuration at 6957.0. evidence_1 and evidence_5 mainly confirm the already-used SABRE objective, normalization, and…
The current relative front-layer and normalized lookahead scoring remains the strongest measured configuration at 6957.0. evidence_1 and evidence_5 mainly confirm the already-used SABRE objective, normalization, and decay formulation, so they provide no clearly new actionable improvement. evidence_3 and evidence_4 suggest weighting lookahead gates by dependency depth using an exponential factor, which is a plausible untested routing refinement, but repository-specific gate-depth information and an implementation path are still missing. evidence_2 proposes a broader candidate neighborhood, dynamic lookahead horizon, exponential lookahead decay, and an explicit reward for immediate gate executability; these are promising hypotheses, but the document does not establish compatible Rust APIs or benchmark-specific parameter choices. The harmful elaborate layout strategy remains rejected, while the component-aware degree/locality layout is retained. What is still needed is either repository-specific implementation knowledge for dependency-depth or executable-gate signals, or controlled benchmark results for these routing changes. The supplied documents do not eliminate that uncertainty.
Kept-document mean prediction 6,964
Query · round 2
"SwapSelectionContext" Rust "front_layer" executable gate can_apply routing API
Find repository-specific APIs or source code for detecting immediately executable front-layer gates and applying or scoring them, enabling a controlled addition of an executability reward or adaptive lookahead without guessing incompatible Rust interfaces.
Query rationale
The current relative front-layer plus normalized lookahead policy is tied at the best measured score of 6957, while the documents suggest immediate-executability rewards and adaptive lookahead as the most promising untested routing refinements. Existing searches established the SABRE formulas and LightSABRE concepts but did not reveal compatible repository APIs. This query targets the missing implementation detail needed for a small, controlled experiment rather than repeating generic heuristic searches.
What this round establishedThe current relative front-layer plus normalized lookahead heuristic with decay remains the strongest measured configuration at 6957.0. The newly scored documents do not provide actionable repository-specific routing…
The current relative front-layer plus normalized lookahead heuristic with decay remains the strongest measured configuration at 6957.0. The newly scored documents do not provide actionable repository-specific routing information: evidence_6 only describes a generic real-routing type without exposing compatible SwapSelectionContext APIs or a usable scoring implementation, while evidence_7 through evidence_10 are unrelated Rust/API-routing material. The dependency-depth weighting hypothesis from evidence_3 and evidence_4 remains plausible but untested, and executable-gate or depth signals are still unavailable. The next useful step is controlled implementation and benchmarking of a small, repository-compatible depth-weighted lookahead variant; no additional knowledge is required from the newly retrieved documents.
Query · round 3
"precomputed_extended_set_logical_pairs" dependency depth BFS layer weighted lookahead Rust SABRE
Find a repository-compatible method for assigning BFS or dependency depths to extended-set gates so the current flat lookahead score can be replaced by a controlled exponential depth-weighted variant.
Query rationale
The current relative front-layer plus flat normalized lookahead with decay is tied for the best measured score at 6957, while the dSABRE documents only establish that gamma^depth weighting is promising and do not expose usable SwapSelectionContext APIs. The next experiment needs a concrete Rust implementation strategy for deriving successor depth or grouping gates by dependency layers without unavailable executable-gate or depth signals.
What this round establishedThe new documents reinforce that depth-weighted lookahead is the most promising next modification: exponential weighting by dependency or BFS depth should make near-term successors more influential than distant…
The new documents reinforce that depth-weighted lookahead is the most promising next modification: exponential weighting by dependency or BFS depth should make near-term successors more influential than distant extended-set gates. Evidence_11 and evidence_12 provide a concrete weighting principle and emphasize dependency-aware BFS-layer construction, while evidence_13 confirms that relative delta scoring and set-size normalization are consistent with the current policy. However, these documents still do not expose repository-specific APIs for attaching dependency depth to precomputed extended-set pairs, and the distributed-routing material in evidence_14 is not directly applicable to this local SWAP router. Evidence_15 is unrelated. The current relative front/lookahead/decay policy remains the strongest measured configuration at 6957.0. No further retrieval is required; the next step is a controlled, repository-compatible implementation and benchmark of depth-weighted extended-set scoring, preferably preserving the current candidate set and decay behavior so its effect can be isolated.
Kept-document mean prediction 6,963
Evidence sent to the solver
"SABRE" adaptive lookahead decay swap scoring weighted interaction frequency initial layout Rust GitHub
"SwapSelectionContext" Rust "front_layer" executable gate can_apply routing API
"precomputed_extended_set_logical_pairs" dependency depth BFS layer weighted lookahead Rust SABRE
Knowledge after searchThe new documents reinforce that depth-weighted lookahead is the most promising next modification: exponential weighting by dependency or BFS depth should make near-term successors more influential than distant…
The new documents reinforce that depth-weighted lookahead is the most promising next modification: exponential weighting by dependency or BFS depth should make near-term successors more influential than distant extended-set gates. Evidence_11 and evidence_12 provide a concrete weighting principle and emphasize dependency-aware BFS-layer construction, while evidence_13 confirms that relative delta scoring and set-size normalization are consistent with the current policy. However, these documents still do not expose repository-specific APIs for attaching dependency depth to precomputed extended-set pairs, and the distributed-routing material in evidence_14 is not directly applicable to this local SWAP router. Evidence_15 is unrelated. The current relative front/lookahead/decay policy remains the strongest measured configuration at 6957.0. No further retrieval is required; the next step is a controlled, repository-compatible implementation and benchmark of depth-weighted extended-set scoring, preferably preserving the current candidate set and decay behavior so its effect can be isolated.
Stop: search budget exhausted
Web sources
Predictions are model estimates before evaluation.
github.comqiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main
The sum of distances for corresponding physical qubits of interacting virtual qubits in the front\_layer. .. math:: H\_{basic} = \sum\_{gate \in F} D[\pi(gate.q\_1)][\pi(gate.q2)] - 'lookahead': This is the sum of two costs: first is the same as the basic cost. Second is the basic cost but now evaluated for the extended set as well (i.e. :math:`|E|` number of upcoming successors to gates in front\_layer F). This is weighted by some amount EXTENDED\_SET\_WEIGHT (W) to signify that upcoming gates are less important than the front\_layer. .. math:: H\_{decay}=\frac{1}{\left|{F}\right|}\sum\_{gate \in F} D[\pi(gate.q\_1)][\pi(gate.q2)] + W\\frac{1}{\left|{E}\right|} \sum\_{gate \in E} D[\pi(gate.q\_1)][\pi(gate.q2)] - 'decay': [...] initial\_layout = NLayout.generate\_trivial\_layout(num\_dag\_qubits) sabre\_start = time.perf\_counter() dag, final\_layout = sabre\_routing( dag, self.\_routing\_target, heuristic, initial\_layout, self.trials, self.seed ) sabre\_stop = time.perf\_counter() LOG.debug("Sabre …
www.researchsquare.comStructured Scaling of AI Discovery Across Diverse Scientific ...
The discovered algorithm can be summarized as follows. First, the discovered algorithm invests heavily in initial layout: it seeds high-degree logical qubits onto central, high-degree physical qubits, and then refines the mapping through an aggressive stack of hill-climbing and restart-based local search. Second, it strengthens online SWAP selection: it broadens the candidate neigh-borhood beyond front-layer incident edges to include look-ahead and shortest-path edges, changes the look-ahead term into dynamic horizon with exponential decay, and reshapes the swap objective to explic-itly reward immediate gate executability. Together, these changes preserve the overall LightSABRE-style structure while materially improving robustness against long-range interactions and stagnation. [...] Initial program. The initial policy is a refactor of Qiskit’s released LightSABRE Rust implementation, em-bedded inside the fixed …
arxiv.orgdSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers
where FF is the front layer, EE the extended lookahead set, and Δ(g)=doldg−dnewg\Delta(g)=d\_{\mathrm{old}}^{g}-d\_{\mathrm{new}}^{g} the reduction in physical distance between the two qubits of gate gg caused by the candidate SWAP (dgd^{g} is shortest-path distance on the coupling graph). All extended-set gates contribute with equal weight; the 1|E|\tfrac{1}{|E|} factor normalises the lookahead term to the same scale as the front term. SABRE also couples its router with an initial-layout optimiser: starting from a random qubit assignment it routes the circuit CC forward, then immediately routes the reverse circuit C−1C^{-1} using the final layout of the forward pass as the new starting point; the layout produced by the [...] ## III dSABRE dSABRE is a SABRE-style routing algorithm for multi-core processors. At …
arxiv.orgdSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers
where FF is the front layer, EE the extended lookahead set, and Δ(g)=doldg−dnewg\Delta(g)=d\_{\mathrm{old}}^{g}-d\_{\mathrm{new}}^{g} the reduction in physical distance between the two qubits of gate gg caused by the candidate SWAP (dgd^{g} is shortest-path distance on the coupling graph). All extended-set gates contribute with equal weight; the 1|E|\tfrac{1}{|E|} factor normalises the lookahead term to the same scale as the front term. SABRE also couples its router with an initial-layout optimiser: starting from a random qubit assignment it routes the circuit CC forward, then immediately routes the reverse circuit C−1C^{-1} using the final layout of the forward pass as the new starting point; the layout produced by the [...] ## III dSABRE dSABRE is a SABRE-style routing algorithm for multi-core processors. At …
quantum.cloud.ibm.comSabreSwap (latest version) | IBM Quantum Documentation
> > ‘lookahead’: > > This is the sum of two costs: first is the same as the basic cost. Second is the basic cost but now evaluated for the extended set as well (i.e. ∣E∣ number of upcoming successors to gates in front\_layer F). This is weighted by some amount EXTENDED\_SET\_WEIGHT (W) to signify that upcoming gates are less important than the front\_layer. > > Hdecay=∣F∣1gate∈F∑D[π(gate.q1)][π(gate.q2)]+W∗∣E∣1gate∈E∑D[π(gate.q1)][π(gate.q2)] > > ‘decay’: > > This is the same as ‘lookahead’, but the whole cost is multiplied by a decay factor. This increases the cost if the SWAP that generated the trial layout was recently used (i.e. it penalizes increase in depth). > [...] > The search space of possible SWAPs on physical …
docs.rsRealRouting in lift_opt::real_routing - Rust
Real layout routing pass. Unlike the legacy LayoutMapping pass (which only annotates gates with needs_swap = true ), this pass performs actual routing: for
tutorialedge.netBuilding an API Gateway in Rust
Add a routing layer to your Rust API gateway so it forwards requests to different backend services based on URL path patterns.
github.comGitHub - lance0/rustbgpd: An API-first BGP daemon in Rust for programmable route-server and control-plane use cases · GitHub
| .pre-commit-config.yaml | .pre-commit-config.yaml | | | | CHANGELOG.md | CHANGELOG.md | | | | CONTRIBUTING.md | CONTRIBUTING.md | | | | Cargo.lock | Cargo.lock | | | | Cargo.toml | Cargo.toml | | | | Dockerfile | Dockerfile | | | | LICENSE-APACHE | LICENSE-APACHE | | | | LICENSE-MIT | LICENSE-MIT | | | | LICENSES.md | LICENSES.md | | | | README.md | README.md | | | | SECURITY.md | SECURITY.md | | | | SUPPORT.md | SUPPORT.md | | | | deny.toml | deny.toml | | | | justfile | justfile | | | | lychee.toml | lychee.toml | | | | pyproject.toml | pyproject.toml | | | | | [...] ``` exec exec ``` Select …
medium.comRust: Google Maps Platform Routes API | by Itsuki
Slowly making my way of building the unofficial google API client for rust, let me share with you the Routes API I have recently added!
docs.rsrou3 - Rust
rou3 is a lightweight and performant HTTP routing library for Rust. It focuses on fast route matching, including support for static paths, parameters (e.g., /:
arxiv.orgdSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers
where γ∈(0,1]\gamma\in(0,1] is the lookahead decay and the distance terms use the intra-core graph. The tilde marks the departure from SABRE’s flat extended-set weighting: rather than treating all lookahead gates equally, the exponential factor γdep(gi)\gamma^{\mathrm{dep}(g\_{i})} down-weights gates far from the front so that near-term successors dominate the lookahead signal — a deeper gate is more likely to be displaced by intervening routing decisions and so contributes less reliable information about the right SWAP now. The same weighted scheme is reused by the inter-core scorer (Section III-C); Section III-D explains how γdep(g)\gamma^{\mathrm{dep}(g)} interacts with the BFS-layer extended set, where dep(g)\mathrm{dep}(g) is the BFS depth rather than an iteration index. [...] ### III-D Inter-Core Extended-Set Construction The lookahead Δ~E\tilde{\Delta}\_{E} in Eq. 4 …
arxiv.orgdSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers
where γ∈(0,1]\gamma\in(0,1] is the lookahead decay and the distance terms use the intra-core graph. The tilde marks the departure from SABRE’s flat extended-set weighting: rather than treating all lookahead gates equally, the exponential factor γdep(gi)\gamma^{\mathrm{dep}(g\_{i})} down-weights gates far from the front so that near-term successors dominate the lookahead signal — a deeper gate is more likely to be displaced by intervening routing decisions and so contributes less reliable information about the right SWAP now. The same weighted scheme is reused by the inter-core scorer (Section III-C); Section III-D explains how γdep(g)\gamma^{\mathrm{dep}(g)} interacts with the BFS-layer extended set, where dep(g)\mathrm{dep}(g) is the BFS depth rather than an iteration index. [...] ### III-D Inter-Core Extended-Set Construction The lookahead Δ~E\tilde{\Delta}\_{E} in Eq. 4 …
arxiv.orgLightSABRE: A Lightweight and Enhanced SABRE Algorithm
where FF and EE are the sets of gates in the front layer and extended set, respectively, and kk is a relative weighting chosen by the implementer. The two sums are over the pairs of physical qubits whose virtual qubits partake in a gate in the relevant set. The function dist(i,j)\dist(i,j) counts the distance between physical qubits ii and jj; two qubits that can directly interact have a distance of unity. The heuristic is a scoring for the total system of the front layer and the extended set under the assumption that a lookahead table for dist\dist—which requires only the hardware topology to be known—is precalculated. Calculation of HH has a computational complexity of Θ(|F|+|E|)\Theta(\lvert F\rvert+\lvert E\rvert). [...] In addition …
arxiv.org[PDF] dSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum ...
1 dSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers Sanjiang Li ∗ Abstract—Minimising EPR consumption is the dominant ob-jective when routing a quantum circuit on a distributed quantum computer (DQC). We present DSABRE, a SABRE-style router for multi-core processors that, on each iteration of a lookahead-driven loop, first resolves any intra-core front-layer gates by SWAP scoring and only falls back to scoring inter-core tele-portation candidates when the intra-core front is empty. Three mechanisms drive the improvement over the state of the art: a five-term gate-centric teleportation score that generalises the local SWAP heuristic to the inter-core setting, whose explicit capacity-penalty term keeps the scorer from teleporting into saturated cores; a proactive congestion-relief pass that redistributes idle qubits out of …
medium.comGraph Algorithms using Depth-First Search (DFS), Breadth- ...
Rust Depth-First Search is a fundamental algorithm used to traverse or search tree or graph data structures. BFS an optimal choice for finding
No recorded documents for this selection.
04Code & measured result
8 candidate attemptsChange 1: Modified struct `ExtendedSetScores` (19→68 lines) Change 2: Near `if !extended_set.is_empty() && self.lookahead_weig...` (5→8 lines)
Code diff recorded excerpt+53−1
+ pairs: Vec<(usize, usize)>,+ self.pairs.push((a, b));+ fn weighted_score_delta(+ swap: (usize, usize),+ if self.pairs.is_empty() {+ let mut weighted = 0.0;+ let mut weights = 0.0;+ for (index, &(x, y)) in self.pairs.iter().enumerate() {+ let weight = gamma.powi(index.min(32) as i32);+ weight * ((topology.distance(nx, ny) as f64)+ - (topology.distance(x, y) as f64));+ weighted * (self.pairs.len() as f64) / weights- *score += lookahead_weight * extended_set.score_delta(*swap, ctx.topology());+ lookahead_weight * extended_set.weighted_score_delta(*swap, ctx.topology());
