{ "key": "swap", "slug": "swap-reduction", "task": "Swap Reduction", "domain": "Quantum compilation", "behavior": "Method transfer", "title": "A better router, one question at a time.", "summary": "Retrieved depth weighting becomes a lasting part of the router, even as later searches repeatedly miss the needed implementation.", "takeaway": "Exponential depth weighting introduced at iteration 5 remains in every later best program. At iteration 77, progress occurs despite a retrieval with no promising document.", "program": "swap-reduction", "model": "GPT-5.6-Luna", "budget": 8, "seed": 42, "edit_mode": "diff edits", "steps": [ { "iteration": 5, "gate": "retrieve", "knowledge_state": "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.", "reasoning": "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.", "queries": [ { "round": 1, "query": "\"SABRE\" adaptive lookahead decay swap scoring weighted interaction frequency initial layout Rust GitHub", "intent": "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." }, { "round": 2, "query": "\"SwapSelectionContext\" Rust \"front_layer\" executable gate can_apply routing API", "intent": "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." }, { "round": 3, "query": "\"precomputed_extended_set_logical_pairs\" dependency depth BFS layer weighted lookahead Rust SABRE", "intent": "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." } ], "sources": [ { "title": "Structured Scaling of AI Discovery Across Diverse Scientific ...", "url": "https://www.researchsquare.com/article/rs-10631214/v1.pdf?c=1787913294000", "predicted_score": 6968.0 }, { "title": "dSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers", "url": "https://arxiv.org/html/2605.21960v1", "predicted_score": 6963.0 }, { "title": "dSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers", "url": "https://arxiv.org/html/2605.21960", "predicted_score": 6963.0 } ], "parent_score": 6957.000000000015, "child_score": 11325.600000000006, "best_before": 6957.000000000015, "best_after": 11325.600000000006, "additions": 53, "deletions": 1, "diff": [ "+ 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());" ], "changes": "Change 1: Modified struct `ExtendedSetScores` (19→68 lines)\nChange 2: Near `if !extended_set.is_empty() && self.lookahead_weig...` (5→8 lines)", "runtime_web_access": false, "evidence": { "gate": { "knowledge": "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.", "reason": "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.", "population": "📊 **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**.\n\n**Key Numbers:**\n• Score distribution: mean **6673.0**, median **6565.8**, and population standard deviation **238.84**. \n• Score spread: the best score is **6957.0** and the worst is **6387.0**, a **570.0-point** range. \n• Score uniqueness: **4 unique scores** occur across **5 programs**, with **2 programs** tied at **6957.0**. \n• 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.\n\n**Patterns Observed:**\n• 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. \n• 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. \n• 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**." }, "rounds": [ { "round": 1, "queries": [ { "query": "\"SABRE\" adaptive lookahead decay swap scoring weighted interaction frequency initial layout Rust GitHub", "intent": "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.", "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.", "keywords": [ "SABRE adaptive heuristic", "weighted interaction graph layout", "Rust router implementation" ], "resources": [ "paper", "github", "docs" ] } ], "retrieved_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "kept_refs": [ "evidence_2", "evidence_3", "evidence_4" ], "predictions": [ { "ref": "evidence_1", "score": 6957.0 }, { "ref": "evidence_2", "score": 6968.0 }, { "ref": "evidence_3", "score": 6962.0 }, { "ref": "evidence_4", "score": 6962.0 }, { "ref": "evidence_5", "score": 6957.0 } ], "kept_mean": 6964.0, "assessment": "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.", "status": "scored", "new_documents": 5 }, { "round": 2, "queries": [ { "query": "\"SwapSelectionContext\" Rust \"front_layer\" executable gate can_apply routing API", "intent": "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.", "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.", "keywords": [ "SwapSelectionContext", "executable gate", "front layer", "Rust routing API" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "candidate_refs": [ "evidence_2", "evidence_3", "evidence_4", "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "kept_refs": [ "evidence_2", "evidence_3", "evidence_4" ], "predictions": [ { "ref": "evidence_6", "score": 6957.0 }, { "ref": "evidence_7", "score": 6957.0 }, { "ref": "evidence_8", "score": 6957.0 }, { "ref": "evidence_9", "score": 6957.0 }, { "ref": "evidence_10", "score": 6957.0 } ], "kept_mean": null, "assessment": "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.", "status": "scored", "new_documents": 5 }, { "round": 3, "queries": [ { "query": "\"precomputed_extended_set_logical_pairs\" dependency depth BFS layer weighted lookahead Rust SABRE", "intent": "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.", "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.", "keywords": [ "Rust SABRE", "dependency depth", "weighted lookahead", "extended set" ], "resources": [ "github", "paper", "docs" ] } ], "retrieved_refs": [ "evidence_11", "evidence_12", "evidence_13", "evidence_14", "evidence_15" ], "candidate_refs": [ "evidence_2", "evidence_3", "evidence_4", "evidence_11", "evidence_12", "evidence_13", "evidence_14", "evidence_15" ], "kept_refs": [ "evidence_2", "evidence_11", "evidence_12" ], "predictions": [ { "ref": "evidence_11", "score": 6963.0 }, { "ref": "evidence_12", "score": 6963.0 }, { "ref": "evidence_13", "score": 6959.0 }, { "ref": "evidence_14", "score": 6958.0 }, { "ref": "evidence_15", "score": 6957.0 } ], "kept_mean": 6963.0, "assessment": "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.", "status": "scored", "new_documents": 5 } ], "documents": [ { "ref": "evidence_1", "url": "https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/routing/sabre_swap.py", "title": "qiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main", "domain": "github.com", "excerpt": "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", "excerpt_truncated": true, "captured_word_count": 270, "rank": 1, "relevance": 0.5832277, "provider": "tavily", "published_date": null, "content_sha256": "8ba8d58c0155580d2eeb766134f5a4402d26cfebd84577352013837543bbf298", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 6957.0 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_2", "url": "https://www.researchsquare.com/article/rs-10631214/v1.pdf?c=1787913294000", "title": "Structured Scaling of AI Discovery Across Diverse Scientific ...", "domain": "www.researchsquare.com", "excerpt": "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", "excerpt_truncated": true, "captured_word_count": 156, "rank": 2, "relevance": 0.48572227, "provider": "tavily", "published_date": null, "content_sha256": "a9a5bb8e0eeccb0f41a2a0a8dd053099e18d24faf6f9626e09491c7b03ed83d0", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 6968.0 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_3", "url": "https://arxiv.org/html/2605.21960", "title": "dSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers", "domain": "arxiv.org", "excerpt": "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", "excerpt_truncated": true, "captured_word_count": 303, "rank": 3, "relevance": 0.47753036, "provider": "tavily", "published_date": null, "content_sha256": "4a40be880b5b5f073832072ceae519ad6c075cd6fe58dbb918817df9b67a5d16", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 6962.0 } ], "kept_rounds": [ 1, 2 ], "for_solver": false }, { "ref": "evidence_4", "url": "https://arxiv.org/html/2605.21960v1", "title": "dSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers", "domain": "arxiv.org", "excerpt": "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", "excerpt_truncated": true, "captured_word_count": 303, "rank": 4, "relevance": 0.47753036, "provider": "tavily", "published_date": null, "content_sha256": "4a40be880b5b5f073832072ceae519ad6c075cd6fe58dbb918817df9b67a5d16", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 6962.0 } ], "kept_rounds": [ 1, 2 ], "for_solver": false }, { "ref": "evidence_5", "url": "https://quantum.cloud.ibm.com/docs/api/qiskit/qiskit.transpiler.passes.SabreSwap", "title": "SabreSwap (latest version) | IBM Quantum Documentation", "domain": "quantum.cloud.ibm.com", "excerpt": "> > ‘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∣1​gate∈F∑​D[π(gate.q1​)][π(gate.q2)]+W∗∣E∣1​gate∈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", "excerpt_truncated": true, "captured_word_count": 195, "rank": 5, "relevance": 0.47475353, "provider": "tavily", "published_date": null, "content_sha256": "a74f943e80c07e9fd261e957229ee7605d9c6151ddb5c5956c21639382ef84ce", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 6957.0 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_6", "url": "https://docs.rs/lift-opt/latest/lift_opt/real_routing/struct.RealRouting.html", "title": "RealRouting in lift_opt::real_routing - Rust", "domain": "docs.rs", "excerpt": "Real layout routing pass. Unlike the legacy LayoutMapping pass (which only annotates gates with needs_swap = true ), this pass performs actual routing: for", "excerpt_truncated": false, "captured_word_count": 24, "rank": 1, "relevance": 0.3738078, "provider": "tavily", "published_date": null, "content_sha256": "e475b6b7234c1ce7a90acfe42390f164d07e234d3d246987260f60b9d3e5d4a2", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 6957.0 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_7", "url": "https://tutorialedge.net/projects/building-api-gateway-in-rust", "title": "Building an API Gateway in Rust", "domain": "tutorialedge.net", "excerpt": "Add a routing layer to your Rust API gateway so it forwards requests to different backend services based on URL path patterns.", "excerpt_truncated": false, "captured_word_count": 22, "rank": 2, "relevance": 0.3430341, "provider": "tavily", "published_date": null, "content_sha256": "9f074d73009c2b82bf30779174b0c83507fd356346d5758b8a84db77aa254c04", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 6957.0 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_8", "url": "https://github.com/lance0/rustbgpd", "title": "GitHub - lance0/rustbgpd: An API-first BGP daemon in Rust for programmable route-server and control-plane use cases · GitHub", "domain": "github.com", "excerpt": "| .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", "excerpt_truncated": true, "captured_word_count": 286, "rank": 3, "relevance": 0.24985929, "provider": "tavily", "published_date": null, "content_sha256": "3eb60a8dc80a5e42b31e4818a589f56b206a9c91a95b0cb30997aee325146e13", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 6957.0 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_9", "url": "https://medium.com/towardsdev/rust-google-maps-platform-routes-api-f17b73001d6f", "title": "Rust: Google Maps Platform Routes API | by Itsuki", "domain": "medium.com", "excerpt": "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!", "excerpt_truncated": false, "captured_word_count": 25, "rank": 4, "relevance": 0.24123052, "provider": "tavily", "published_date": null, "content_sha256": "b1d05d64d57122a7677286baeea7524152e4946735adc8209d3d2c4c2aba6514", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 6957.0 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_10", "url": "https://docs.rs/rou3", "title": "rou3 - Rust", "domain": "docs.rs", "excerpt": "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., /:", "excerpt_truncated": false, "captured_word_count": 25, "rank": 5, "relevance": 0.23398674, "provider": "tavily", "published_date": null, "content_sha256": "91244547a3fcd3829e5fe2131e0628f7ea2f8bb6e79a0813792e8b5515c91a11", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 6957.0 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_11", "url": "https://arxiv.org/html/2605.21960v1", "title": "dSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers", "domain": "arxiv.org", "excerpt": "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", "excerpt_truncated": true, "captured_word_count": 254, "rank": 1, "relevance": 0.5883458, "provider": "tavily", "published_date": null, "content_sha256": "5c395664c190682fe7719661ce98728b1f94f3b52a5965b78e7a367759c2b773", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 6963.0 } ], "kept_rounds": [ 3 ], "for_solver": true }, { "ref": "evidence_12", "url": "https://arxiv.org/html/2605.21960", "title": "dSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum Computers", "domain": "arxiv.org", "excerpt": "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", "excerpt_truncated": true, "captured_word_count": 254, "rank": 2, "relevance": 0.5883458, "provider": "tavily", "published_date": null, "content_sha256": "5c395664c190682fe7719661ce98728b1f94f3b52a5965b78e7a367759c2b773", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 6963.0 } ], "kept_rounds": [ 3 ], "for_solver": true }, { "ref": "evidence_13", "url": "https://arxiv.org/html/2409.08368v1", "title": "LightSABRE: A Lightweight and Enhanced SABRE Algorithm", "domain": "arxiv.org", "excerpt": "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", "excerpt_truncated": true, "captured_word_count": 269, "rank": 3, "relevance": 0.38477397, "provider": "tavily", "published_date": null, "content_sha256": "1338f38a1f33d2afb02bab3077a788b71fa8b9d8f35691dd2649faca4874222d", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 6959.0 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_14", "url": "https://arxiv.org/pdf/2605.21960", "title": "[PDF] dSABRE: A SABRE-Style Router for Multi-Core Distributed Quantum ...", "domain": "arxiv.org", "excerpt": "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", "excerpt_truncated": true, "captured_word_count": 372, "rank": 4, "relevance": 0.22479525, "provider": "tavily", "published_date": null, "content_sha256": "1bb63e39799b4fb76148a1a41d0eb41cff4a6c980c736be26e7beeab1fc91f4f", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 6958.0 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_15", "url": "https://medium.com/coinmonks/graph-algorithms-using-depth-first-search-dfs-breadth-first-search-bfs-and-dijkstras-e911367a44a4", "title": "Graph Algorithms using Depth-First Search (DFS), Breadth- ...", "domain": "medium.com", "excerpt": "Rust Depth-First Search is a fundamental algorithm used to traverse or search tree or graph data structures. BFS an optimal choice for finding", "excerpt_truncated": false, "captured_word_count": 23, "rank": 5, "relevance": 0.18277569, "provider": "tavily", "published_date": null, "content_sha256": "521c3fe797aa71b62db01a0c1144e5813cedeeb57b5fe0bee42f4a7de29d2f01", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 6957.0 } ], "kept_rounds": [], "for_solver": false } ], "final_knowledge": "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_reason": "search_budget_exhausted", "search_attempts": 3, "status": "evaluated", "generation_condition": { "num_generations": 8, "score_target": "best_valid_child_of_n_attempts" }, "predicted_score": null, "excerpt_note": "Excerpts from the saved retrieval, up to 120 words per document. Scores are model predictions before evaluation.", "checkpoint_available": true } }, { "iteration": 7, "gate": "retrieve", "knowledge_state": "The prior attempts established a substantial measured improvement from 6498 to 11325.6, but the three listed attempts have identical routing metrics, so they do not isolate which modifications caused the gain or whether the current heuristic is near a plateau. Existing documents support geometric lookahead decay and LightSABRE concepts such as depth, critical-path scoring, broader candidate neighborhoods, and immediate executability rewards. However, they do not provide the exact Rust SwapSelectionContext APIs or enough implementation detail to safely add those features, nor do they resolve whether the current topological-order weighting should be replaced by BFS-depth weighting. The remaining knowledge needed is concrete source-level guidance for the current router, especially available context methods for depth/critical-path data, executable-gate scoring, and candidate generation.", "reasoning": "Additional evidence would help because the next promising improvements require implementation details absent from the stored documents. Reusing the existing high-level papers would largely repeat explored knowledge; a fresh search should target the exact Rust routing implementation and APIs, as well as validated LightSABRE candidate and scoring behavior.", "queries": [ { "round": 1, "query": "site:github.com/Qiskit/qiskit \"SwapSelectionContext\" \"critical_path\" OR \"delta_depth\" OR \"can_apply\" Rust", "intent": "Find the current Rust SwapSelectionContext APIs and implementation for LightSABRE depth, critical-path, immediate-executability, and broader candidate-swap scoring." }, { "round": 2, "query": "site:github.com/Qiskit/qiskit \"SwapSelectionContext\" \"precomputed_extended_set_logical_pairs\" \"remaining_predecessor_counts\" Rust sabre", "intent": "Find the current Qiskit Rust source implementation and concrete SwapSelectionContext APIs for BFS/dependency-depth extended-set construction, immediate gate executability checks, and safe broader candidate generation." }, { "round": 3, "query": "site:github.com/Qiskit/qiskit \"SwapSelectionContext\" \"precomputed_extended_set_logical_pairs\" \"remaining_predecessor_counts\" Rust sabre", "intent": "Find the current Qiskit Rust source implementation and concrete SwapSelectionContext APIs for BFS/dependency-depth extended-set construction, immediate gate executability checks, and safe broader candidate generation." } ], "sources": [ { "title": "Port the rest of `SabreSwap` to Rust · Issue #12280 · Qiskit/qiskit · GitHub", "url": "https://github.com/Qiskit/qiskit/issues/12280", "predicted_score": 11325.6 }, { "title": "qiskit/rust-toolchain.toml at main · Qiskit/qiskit · GitHub", "url": "https://github.com/Qiskit/qiskit/blob/main/rust-toolchain.toml", "predicted_score": 11325.6 }, { "title": "Port the rest of `SabreLayout` to Rust · Issue #12279 · Qiskit/qiskit · GitHub", "url": "https://github.com/Qiskit/qiskit/issues/12279", "predicted_score": 11325.6 } ], "parent_score": 11325.600000000006, "child_score": 15174.00000000003, "best_before": 11325.600000000006, "best_after": 15174.00000000003, "additions": 19, "deletions": 9, "diff": [ "- let gamma = 0.84_f64;", "+ let gamma = 0.70_f64;", "- let Some((a, b)) = ctx.last_applied_swap() else {", "- return;", "- } else {", "+ } else if let Some((a, b)) = ctx.last_applied_swap() {", "+ let penalty_scale = (front_layer.len().max(1) as f64).sqrt() * 0.10;", "- *score *= self.decay_state[swap.0].max(self.decay_state[swap.1]);", "+ let endpoint_decay =", "+ (self.decay_state[swap.0] - 1.0).max(self.decay_state[swap.1] - 1.0);", "+ *score += penalty_scale * endpoint_decay;", "+ if ctx.last_applied_swap() == Some(*swap)", "+ || ctx.last_applied_swap() == Some((swap.1, swap.0))", "+ *score += penalty_scale * 0.25;" ], "changes": "Change 1: Near `fn refresh_decay_state(&mut self, ctx: &SwapSelect...` (26→25 lines)\nChange 2: 'let gamma = 0.84_f64;' → 'let gamma = 0.70_f64;'\nChange 3: Near `// Only relative changes affect the choice. Includ...` (8→19 lines)", "runtime_web_access": false, "evidence": { "gate": { "knowledge": "The prior attempts established a substantial measured improvement from 6498 to 11325.6, but the three listed attempts have identical routing metrics, so they do not isolate which modifications caused the gain or whether the current heuristic is near a plateau. Existing documents support geometric lookahead decay and LightSABRE concepts such as depth, critical-path scoring, broader candidate neighborhoods, and immediate executability rewards. However, they do not provide the exact Rust SwapSelectionContext APIs or enough implementation detail to safely add those features, nor do they resolve whether the current topological-order weighting should be replaced by BFS-depth weighting. The remaining knowledge needed is concrete source-level guidance for the current router, especially available context methods for depth/critical-path data, executable-gate scoring, and candidate generation.", "reason": "Additional evidence would help because the next promising improvements require implementation details absent from the stored documents. Reusing the existing high-level papers would largely repeat explored knowledge; a fresh search should target the exact Rust routing implementation and APIs, as well as validated LightSABRE candidate and scoring behavior.", "population": "📊 **State:** The retained population contains **8 programs** with scores from **6387.0 to 11325.6**, and the current parent is tied for the retained best at **11325.6**.\n\n**Key Numbers:**\n• Score distribution: mean **8417.7**, median **6957.0**, and population standard deviation **2260.35**. \n• Score diversity: **5 unique scores** among **8 programs**; the best score is **11325.6** and the worst is **6387.0**. \n• Trajectory: scores rose from **6387.0 at iteration 0** to **11325.6 at iteration 5**, followed by an unchanged result of **11325.6 at iteration 6**. \n• Current parent: score **11325.6**, with a **0.0** gap to the retained best.\n\n**Patterns Observed:**\n• Parent selection: **7** parent-selection slots used **4** unique IDs; the most-selected parent was selected **3 times** (**42.86%**) and had score **6498.0**. \n• Context selection: **10** context-selection slots used **6** unique IDs; the most-selected context appeared **3 times** (**75%** of the **4** programs with context selections) and had score **6957.0**. \n• Outcomes: retained improvements included deltas of **111.0**, **67.8**, **570.0**, **459.0**, **4368.6**, and **4827.6**; the largest resulting score was **11325.6**, while one iteration-6 result was **unchanged at 0.0**." }, "rounds": [ { "round": 1, "queries": [ { "query": "site:github.com/Qiskit/qiskit \"SwapSelectionContext\" \"critical_path\" OR \"delta_depth\" OR \"can_apply\" Rust", "intent": "Find the current Rust SwapSelectionContext APIs and implementation for LightSABRE depth, critical-path, immediate-executability, and broader candidate-swap scoring.", "rationale": "Previous searches mostly returned Python documentation and papers without source-level Rust details, while the current program has plateaued at 11325.6 and already uses geometric lookahead and topological-order successors. Concrete method names and signatures would enable a safe next experiment adding executable-gate rewards, depth or critical-path deltas, or BFS-aware candidate generation without guessing unavailable APIs.", "keywords": [ "SwapSelectionContext", "critical_path", "delta_depth", "can_apply" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [ { "ref": "evidence_1", "score": 11325.6 }, { "ref": "evidence_2", "score": 11325.6 }, { "ref": "evidence_3", "score": 11325.6 }, { "ref": "evidence_4", "score": 11325.6 }, { "ref": "evidence_5", "score": 11325.6 } ], "kept_mean": 11325.6, "assessment": "The new documents do not provide actionable routing guidance. Evidence 1 concerns a historical issue about porting SabreSwap to Rust, evidence 3 concerns SabreLayout porting, evidence 4 concerns QPY infrastructure, and evidence 2 is only toolchain metadata. Evidence 5 describes general Rust gate infrastructure but exposes no SwapSelectionContext methods, executable-gate scoring, depth tracking, critical-path data, or candidate-generation APIs. Thus the current geometric lookahead and layout changes remain the only measured high-performing approach at 11325.6, with recent variants producing identical routing metrics and no evidence of further improvement. The main missing knowledge is still concrete source-level access to the current router implementation and context API, particularly BFS/dependency-depth extended-set construction, immediate executability checks, depth or critical-path scoring, and broader safe candidate generation. These features remain untested rather than disproven; speculative implementation without API details is still high risk.", "status": "scored", "new_documents": 5 }, { "round": 2, "queries": [ { "query": "site:github.com/Qiskit/qiskit \"SwapSelectionContext\" \"precomputed_extended_set_logical_pairs\" \"remaining_predecessor_counts\" Rust sabre", "intent": "Find the current Qiskit Rust source implementation and concrete SwapSelectionContext APIs for BFS/dependency-depth extended-set construction, immediate gate executability checks, and safe broader candidate generation.", "rationale": "The current geometric lookahead and layout changes are tied at the best score, while recent variants are unchanged. Existing searches returned high-level papers and GitHub issues rather than the router source, leaving executable-gate checks, dependency depth, and candidate-generation APIs untested. Locating the exact Rust implementation would enable a targeted, compilable improvement instead of speculative API changes.", "keywords": [ "SwapSelectionContext", "precomputed_extended_set_logical_pairs", "remaining_predecessor_counts", "Rust SABRE" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [ { "ref": "evidence_6", "score": 11325.6 }, { "ref": "evidence_7", "score": 11325.6 }, { "ref": "evidence_8", "score": 11325.6 }, { "ref": "evidence_9", "score": 11325.6 }, { "ref": "evidence_10", "score": 11325.6 } ], "kept_mean": null, "assessment": "The new documents do not provide actionable routing guidance. Evidence 1 concerns a historical issue about porting SabreSwap to Rust, evidence 3 concerns SabreLayout porting, evidence 4 concerns QPY infrastructure, and evidence 2 is only toolchain metadata. Evidence 5 describes general Rust gate infrastructure but exposes no SwapSelectionContext methods, executable-gate scoring, depth tracking, critical-path data, or candidate-generation APIs. Thus the current geometric lookahead and layout changes remain the only measured high-performing approach at 11325.6, with recent variants producing identical routing metrics and no evidence of further improvement. The main missing knowledge is still concrete source-level access to the current router implementation and context API, particularly BFS/dependency-depth extended-set construction, immediate executability checks, depth or critical-path scoring, and broader safe candidate generation. These features remain untested rather than disproven; speculative implementation without API details is still high risk.", "status": "partial", "new_documents": 5 }, { "round": 3, "queries": [ { "query": "site:github.com/Qiskit/qiskit \"SwapSelectionContext\" \"precomputed_extended_set_logical_pairs\" \"remaining_predecessor_counts\" Rust sabre", "intent": "Find the current Qiskit Rust source implementation and concrete SwapSelectionContext APIs for BFS/dependency-depth extended-set construction, immediate gate executability checks, and safe broader candidate generation.", "rationale": "The current geometric lookahead and layout changes are tied at the best score, while recent variants are unchanged. Existing searches returned high-level papers and GitHub issues rather than the router source, leaving executable-gate checks, dependency depth, and candidate-generation APIs untested. Locating the exact Rust implementation would enable a targeted, compilable improvement instead of speculative API changes.", "keywords": [ "SwapSelectionContext", "precomputed_extended_set_logical_pairs", "remaining_predecessor_counts", "Rust SABRE" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [], "kept_mean": null, "assessment": "The new documents do not provide actionable routing guidance. Evidence 1 concerns a historical issue about porting SabreSwap to Rust, evidence 3 concerns SabreLayout porting, evidence 4 concerns QPY infrastructure, and evidence 2 is only toolchain metadata. Evidence 5 describes general Rust gate infrastructure but exposes no SwapSelectionContext methods, executable-gate scoring, depth tracking, critical-path data, or candidate-generation APIs. Thus the current geometric lookahead and layout changes remain the only measured high-performing approach at 11325.6, with recent variants producing identical routing metrics and no evidence of further improvement. The main missing knowledge is still concrete source-level access to the current router implementation and context API, particularly BFS/dependency-depth extended-set construction, immediate executability checks, depth or critical-path scoring, and broader safe candidate generation. These features remain untested rather than disproven; speculative implementation without API details is still high risk.", "status": "no_new_documents", "new_documents": 0 } ], "documents": [ { "ref": "evidence_1", "url": "https://github.com/Qiskit/qiskit/issues/12280", "title": "Port the rest of `SabreSwap` to Rust · Issue #12280 · Qiskit/qiskit · GitHub", "domain": "github.com", "excerpt": "## Navigation Menu ### Uh oh! There was an error while loading. Please reload this page. There was an error while loading. Please reload this page. # Port the rest of `SabreSwap` to Rust #12280 `SabreSwap` `SabreSwap` jakelishman ## Description @mtreinish `SabreSwap` is primarily written in rust currently, there is just a small component of the pass which takes the python objects representing the `DAGCircuit` and backend constraints and builds rust objects from those, then after the rust code finishes another piece uses the return from rust to rebuild the dagcircuit with the extra swaps inserted in python. Once #11721 is implemented we can remove this python space component and build the dagcircuit directly in rust and never need any", "excerpt_truncated": true, "captured_word_count": 158, "rank": 1, "relevance": 0.079560205, "provider": "tavily", "published_date": null, "content_sha256": "758b3c3eb4e91bf5f47212cdde044f39fa1160e7843e9aabe3149d7aa3ff7580", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 11325.6 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_2", "url": "https://github.com/Qiskit/qiskit/blob/main/rust-toolchain.toml", "title": "qiskit/rust-toolchain.toml at main · Qiskit/qiskit · GitHub", "domain": "github.com", "excerpt": "/ # rust-toolchain.toml Copy path ## File metadata and controls 10 lines (10 loc) · 156 Bytes Raw Copy raw file Download raw file Open symbols panel Edit and raw actions 1 2 3 4 5 6 7 8 9 [toolchain] # Keep in sync with Cargo.toml's `rust-version`. channel = \"1.89\" components = [ \"cargo\", \"clippy\", \"rust-std\", \"rustc\", \"rustfmt\", You can’t perform that action at this time. [...] Skip to content ## Navigation Menu Sign in Appearance settings Sign in Sign up Appearance settings You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to", "excerpt_truncated": true, "captured_word_count": 193, "rank": 2, "relevance": 0.035320852, "provider": "tavily", "published_date": null, "content_sha256": "e2207f663e2cabc105f9869f4d91f12edaeedbc117df7bb2661ec254a8890227", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 11325.6 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_3", "url": "https://github.com/Qiskit/qiskit/issues/12279", "title": "Port the rest of `SabreLayout` to Rust · Issue #12279 · Qiskit/qiskit · GitHub", "domain": "github.com", "excerpt": "## Navigation Menu ### Uh oh! There was an error while loading. Please reload this page. There was an error while loading. Please reload this page. # Port the rest of `SabreLayout` to Rust #12279 `SabreLayout` `SabreLayout` jakelishman ## Description @mtreinish [...] ## Description @mtreinish `SabreLayout` is primarily written in rust currently, there is just a small component of the pass which takes the python objects representing the `DAGCircuit` and backend constraints and builds rust objects from those, then after the rust code finishes another piece uses the return from rust to rebuild the dagcircuit in python. Once #11721 is implemented (and probably #12261 #12262 #12260 too) we can remove this python space component and build the dagcircuit directly in", "excerpt_truncated": true, "captured_word_count": 162, "rank": 3, "relevance": 0.0335294, "provider": "tavily", "published_date": null, "content_sha256": "a064e78b3ec0334f9a946c9b4219c442f3124ebdab3b11866e68ec5e9db63489", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 11325.6 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_4", "url": "https://github.com/Qiskit/qiskit/issues/15662", "title": "Full Rust QPY flow · Issue #15662 · Qiskit/qiskit · GitHub", "domain": "github.com", "excerpt": "## Navigation Menu ### Uh oh! There was an error while loading. Please reload this page. There was an error while loading. Please reload this page. # Full Rust QPY flow #15662 gadial ## Description @gadial ### What should we add? In the current QPY flow, the rust entrypoint are the `write_circuit` and `read_circuit` methods. The header and circuit tables are still handled by Python's `dump` and `load` methods. We should port these parts of the code to Rust as well and achieve full Python independence. `write_circuit` `read_circuit` `dump` `load` ## Activity ## Metadata ## Metadata ### Assignees @gadial ### Labels ### Type ### Projects ### Milestone ### Relationships ### Development ## Issue actions ## Footer ### Footer navigation", "excerpt_truncated": false, "captured_word_count": 119, "rank": 4, "relevance": 0.029226275, "provider": "tavily", "published_date": null, "content_sha256": "47a5d6472ac292fcfcaebfa0cb4aeb71b562fa58c225578c156569db5b6c98ef", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 11325.6 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_5", "url": "https://github.com/Qiskit/qiskit/pull/12459", "title": "Add infrastructure for gates, instruction, and operations in Rust by mtreinish · Pull Request #12459 · Qiskit/qiskit · GitHub", "domain": "github.com", "excerpt": "Title: Add infrastructure for gates, instruction, and operations in Rust by mtreinish · Pull Request #12459 · Qiskit/qiskit · GitHub # Add infrastructure for gates, instruction, and operations in Rust#12459. This commit adds a native representation of Gates, Instruction, and Operations to rust's circuit module. This commit updates the QuantumCircuit gate methods which add a given gate to the circuit to bypass the python gate object creation and directly insert a rust representation of the gate. * Add: __sub__ method to GateMapKeys. - Fix repeated erroneous calls to `add_instruction` in `update_from_instruction_schedule_map`. * Add: rust native functions to target. * Fix: Wrong return value for `BaseTarget.qargs`. * Add: Native representation of coupling graph. * Add: `get_non_global_op_names` as a rust native function.", "excerpt_truncated": true, "captured_word_count": 375, "rank": 5, "relevance": 0.028961461, "provider": "tavily", "published_date": null, "content_sha256": "469b65f1d75d151ed528323303c43cfbff0163ab1a63d36e0ebeea28c98a7286", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 11325.6 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_6", "url": "https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/routing/sabre_swap.py", "title": "qiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main", "domain": "github.com", "excerpt": "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': [...] 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36", "excerpt_truncated": true, "captured_word_count": 411, "rank": 1, "relevance": 0.37360206, "provider": "tavily", "published_date": null, "content_sha256": "c73b3377e5aecbfb5987cba872261c87ee32f3ed605be80df5742a913f89f358", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 11325.6 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_7", "url": "https://github.com/Qiskit/qiskit/pull/12780", "title": "Add config option to leverage all cores for sabre by mtreinish · Pull Request #12780 · Qiskit/qiskit · GitHub", "domain": "github.com", "excerpt": "Title: Add config option to leverage all cores for sabre by mtreinish · Pull Request #12780 · Qiskit/qiskit · GitHub ## Use saved searches to filter your results more quickly. # Add config option to leverage all cores for sabre#12780. However when running qiskit on systems with a lot of CPUs available we're leaving potential performance on the table by not using all the available cores. This new flag lets users opt-in to running sabre with n trials for n CPUs to potentially get better output results from the transpiler, with minimal to no runtime overhead, at the cost of the results not necessarily being reproducible when run on a different computer. | One or more of the following people", "excerpt_truncated": true, "captured_word_count": 372, "rank": 2, "relevance": 0.08904994, "provider": "tavily", "published_date": null, "content_sha256": "8f6d5eaa2293f036ce345d90fafc6a04384370083fd470451ed0e8360c90dc4c", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 11325.6 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_8", "url": "https://github.com/Qiskit/qiskit/issues/9090", "title": "sabre algorithm improvements in transpilation at level 3 not in effect", "domain": "github.com", "excerpt": "Skip to content ## Navigation Menu Sign in Appearance settings Sign in Sign up Appearance settings You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert {{ message }} ### Uh oh! There was an error while loading. Please reload this page. Qiskit / qiskit Public Notifications You must be signed in to change notification settings Fork 3k Star 7.8k # sabre algorithm improvements in transpilation at level 3 not in effect #9090 Copy link Copy link Closed #9116 Closed sabre algorithm improvements in transpilation at level 3 not", "excerpt_truncated": true, "captured_word_count": 265, "rank": 3, "relevance": 0.081381105, "provider": "tavily", "published_date": null, "content_sha256": "993487ab5383d7c166fca49c094b27fe9e10ee283b22ee52f9c4a3d70766f7b0", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 11325.6 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_9", "url": "https://github.com/Qiskit/qiskit/pull/12841", "title": "Add config option to leverage all cores for sabre (backport #12780) by mergify[bot] · Pull Request #12841 · Qiskit/qiskit · GitHub", "domain": "github.com", "excerpt": "Title: Add config option to leverage all cores for sabre (backport #12780) by mergify[bot] · Pull Request #12841 · Qiskit/qiskit · GitHub ## Navigation Menu. # Search code, repositories, users, issues, pull requests... # Saved searches. ## Use saved searches to filter your results more quickly. # Add config option to leverage all cores for sabre (backport #12780)#12841. ## Conversation. ### @mergify **mergify Bot** commented Jul 29, 2024. By default when running sabre in parallel we use a fixed number of threads (depending on optimization level). This was a tradeoff made for having deterministic results across multiple systems with a fixed seed set. ### Details and comments --- This is an automatic backport of pull request #12780 done by Mergify.", "excerpt_truncated": true, "captured_word_count": 384, "rank": 4, "relevance": 0.06819553, "provider": "tavily", "published_date": null, "content_sha256": "e5be6a3fdfcea3fee4a4e951d881fe6315ccbf91269423ba9529b75162ca108b", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 11325.6 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_10", "url": "https://github.com/Qiskit/qiskit/issues/10232", "title": "Add support for `Expr` values to `SabreSwap` and `SabreLayout` · Issue #10232 · Qiskit/qiskit · GitHub", "domain": "github.com", "excerpt": "Title: Add support for `Expr` values to `SabreSwap` and `SabreLayout` · Issue #10232 · Qiskit/qiskit · GitHub ## Navigation Menu. # Search code, repositories, users, issues, pull requests... # Provide feedback. We read every piece of feedback, and take your input very seriously. # Saved searches. ## Use saved searches to filter your results more quickly. To see all available qualifiers, see our documentation. # Add support for `Expr` values to `SabreSwap` and `SabreLayout` #10232. ## Description. ### What should we add? Our Sabre implementation works by having Python-space pass a stripped-down, minimal version of the data-flow dependencies down to the Rust layer. This involves a step where wires need to be copied into the new data structures. For historical", "excerpt_truncated": true, "captured_word_count": 237, "rank": 5, "relevance": 0.06738094, "provider": "tavily", "published_date": null, "content_sha256": "a21f0259226bca338b4fd9c2d5922bbbbdf847c476d6956ebe7d31a3a494df68", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 11325.6 } ], "kept_rounds": [], "for_solver": false } ], "final_knowledge": "The new documents do not provide actionable routing guidance. Evidence 1 concerns a historical issue about porting SabreSwap to Rust, evidence 3 concerns SabreLayout porting, evidence 4 concerns QPY infrastructure, and evidence 2 is only toolchain metadata. Evidence 5 describes general Rust gate infrastructure but exposes no SwapSelectionContext methods, executable-gate scoring, depth tracking, critical-path data, or candidate-generation APIs. Thus the current geometric lookahead and layout changes remain the only measured high-performing approach at 11325.6, with recent variants producing identical routing metrics and no evidence of further improvement. The main missing knowledge is still concrete source-level access to the current router implementation and context API, particularly BFS/dependency-depth extended-set construction, immediate executability checks, depth or critical-path scoring, and broader safe candidate generation. These features remain untested rather than disproven; speculative implementation without API details is still high risk.", "stop_reason": "search_budget_exhausted", "search_attempts": 3, "status": "evaluated", "generation_condition": { "num_generations": 8, "score_target": "best_valid_child_of_n_attempts" }, "predicted_score": null, "excerpt_note": "Excerpts from the saved retrieval, up to 120 words per document. Scores are model predictions before evaluation.", "checkpoint_available": true } }, { "iteration": 13, "gate": "retrieve", "knowledge_state": "The strongest measured configuration achieves a combined score of 15493.8 with gamma=0.70, lookahead_size=16, interaction-aware initial layout, and multiplicative endpoint decay. Prior experiments show that geometric lookahead and corrected relative-score handling improve substantially over the weaker baselines, while additive decay and slower gamma=0.84 were not independently superior. Retrieved documents establish the standard SABRE heuristic and indicate that recent Qiskit work changed extended-set tracking to layer-based and on-the-fly construction, but they do not provide the Rust implementation details needed to reproduce that behavior. The current build_extended_set still uses a flattened topological traversal and assigns decay by iteration index rather than explicit dependency/BFS layer depth. It is therefore unresolved whether layer-based extended-set construction, depth-aware weighting, or other current LightSABRE details can improve the measured result without harming validity or runtime.", "reasoning": "Additional evidence would help because the next promising change depends on exact recent Rust/Qiskit extended-set layer-tracking semantics, which are only described at a high level in the stored documents. Fresh exploration should target the actual pull-request diffs or current sabre Rust source, especially layer maintenance, successor admission, and depth-based weighting.", "queries": [ { "round": 1, "query": "site:github.com/Qiskit/qiskit/pull/14911/files OR site:github.com/Qiskit/qiskit/pull/14912/files Rust sabre extended set BFS layers depth on-the-fly raw diff", "intent": "Find the exact Rust or accelerated implementation changes from Qiskit PRs #14911 and #14912, especially how the extended set is constructed by dependency layers and updated on the fly, and whether weighting uses BFS layer depth rather than flattened traversal order." }, { "round": 2, "query": "site:github.com/Qiskit/qiskit/pull/14912/files OR site:github.com/Qiskit/qiskit/blob/main/qiskit/_accelerate \"precomputed_extended_set_logical_pairs\" \"update\" \"layer\" sabre.rs", "intent": "Find the actual Rust implementation or patch for SABRE's on-the-fly, layer-based extended-set maintenance, including how dependency layers and gate ordering are represented and updated after swaps or front-layer progress." }, { "round": 3, "query": "site:github.com/Qiskit/qiskit/pull/14912/files OR site:github.com/Qiskit/qiskit/blob/main/qiskit/_accelerate \"precomputed_extended_set_logical_pairs\" \"update\" \"layer\" sabre.rs", "intent": "Find the actual Rust implementation or patch for SABRE's on-the-fly, layer-based extended-set maintenance, including how dependency layers and gate ordering are represented and updated after swaps or front-layer progress." } ], "sources": [ { "title": "Releases · Qiskit/qiskit - GitHub", "url": "https://github.com/qiskit/qiskit/releases", "predicted_score": 15493.8 }, { "title": "qiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main", "url": "https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/routing/sabre_swap.py", "predicted_score": 15493.8 }, { "title": "[PDF] arXiv:2205.10596v1 [quant-ph] 21 May 2022", "url": "https://arxiv.org/pdf/2205.10596", "predicted_score": 15493.8 } ], "parent_score": 15493.800000000017, "child_score": 16871.40000000001, "best_before": 15493.800000000017, "best_after": 16871.40000000001, "additions": 34, "deletions": 5, "diff": [ "+ fn completion_bonus(&self, swap: (usize, usize), topology: TopologyView<'_>) -> f64 {", "+ let (a, b) = swap;", "+ let mut bonus = 0.0;", "+ for &[x, y] in &self.nodes {", "+ let old_distance = topology.distance(x, y);", "+ let nx = if x == a { b } else if x == b { a } else { x };", "+ let ny = if y == a { b } else if y == b { a } else { y };", "+ if old_distance > 1 && topology.distance(nx, ny) == 1 {", "+ for &node_id in circuit.first_layer_node_ids() {", "+ if let Some((a, b)) = circuit.node(node_id).two_qubit_pair() {", "+ logical_degree[a] += 3;", "+ logical_degree[b] += 3;", "+ *score -= basic_weight", "+ * front_layer.completion_bonus(*swap, ctx.topology());" ], "changes": "Change 1: Near `fn score_delta(&self, swap: (usize, usize), topolo...` (12→29 lines)\nChange 2: Near `// Score only candidate-induced distance changes; ...` (5→10 lines)\nChange 3: Near `// Rank logical qubits by interaction frequency an...` (10→17 lines)", "runtime_web_access": false, "evidence": { "gate": { "knowledge": "The strongest measured configuration achieves a combined score of 15493.8 with gamma=0.70, lookahead_size=16, interaction-aware initial layout, and multiplicative endpoint decay. Prior experiments show that geometric lookahead and corrected relative-score handling improve substantially over the weaker baselines, while additive decay and slower gamma=0.84 were not independently superior. Retrieved documents establish the standard SABRE heuristic and indicate that recent Qiskit work changed extended-set tracking to layer-based and on-the-fly construction, but they do not provide the Rust implementation details needed to reproduce that behavior. The current build_extended_set still uses a flattened topological traversal and assigns decay by iteration index rather than explicit dependency/BFS layer depth. It is therefore unresolved whether layer-based extended-set construction, depth-aware weighting, or other current LightSABRE details can improve the measured result without harming validity or runtime.", "reason": "Additional evidence would help because the next promising change depends on exact recent Rust/Qiskit extended-set layer-tracking semantics, which are only described at a high level in the stored documents. Fresh exploration should target the actual pull-request diffs or current sabre Rust source, especially layer maintenance, successor admission, and depth-based weighting.", "population": "📊 **State:** The retained population contains **16 programs** with scores from **6,387.0** to **15,493.8**, while the trace reaches **15,493.8** by iteration **12**.\n\n**Key Numbers:**\n• Score distribution: mean **11,683.05**, median **11,464.2**, and population standard deviation **3,744.66**. \n• Score range: worst **6,387.0**, best **15,493.8**, with **9** unique scores across **16** programs. \n• Current parent score: **15,493.8**, with a **0.0** gap to the retained best. \n• Trace trajectory: scores rose from **6,387.0** at iteration **0** to **15,493.8** at iteration **12**; the largest listed improvement was **8,536.8** at iteration **9**.\n\n**Patterns Observed:**\n• The top score **15,493.8** appears for **5** programs, while **3** programs score **11,325.6** and **2** score **6,957.0**. \n• In the **16** trace rows, **11** outcomes were improved, **3** were unchanged, **1** regressed, and **1** had no parent. \n• Parent selection used **15** slots across **10** unique programs; the most-selected parent was selected **3** times, or **20%** of slots. Context selection used **23** slots across **10** unique programs; the most-selected context was selected **5** times, or **62.5%** of programs with context selection." }, "rounds": [ { "round": 1, "queries": [ { "query": "site:github.com/Qiskit/qiskit/pull/14911/files OR site:github.com/Qiskit/qiskit/pull/14912/files Rust sabre extended set BFS layers depth on-the-fly raw diff", "intent": "Find the exact Rust or accelerated implementation changes from Qiskit PRs #14911 and #14912, especially how the extended set is constructed by dependency layers and updated on the fly, and whether weighting uses BFS layer depth rather than flattened traversal order.", "rationale": "The current program already reaches the best measured score with gamma=0.70 and a 16-gate horizon, but build_extended_set still uses flattened topological traversal and index-based decay. Exact upstream implementation details could enable a validity-preserving layer-based extended set, depth-aware geometric weighting, and incremental updates without guessing at dependency handling or harming runtime.", "keywords": [ "Qiskit SABRE Rust", "extended set BFS layers", "on-the-fly tracking", "depth-aware weighting" ], "resources": [ "github", "paper", "docs" ] } ], "retrieved_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [ { "ref": "evidence_1", "score": 15493.8 }, { "ref": "evidence_2", "score": 15493.8 }, { "ref": "evidence_3", "score": 15493.8 }, { "ref": "evidence_4", "score": 15493.8 }, { "ref": "evidence_5", "score": 15493.8 } ], "kept_mean": 15493.799999999997, "assessment": "The new documents reinforce that current Qiskit SABRE development uses layer-based lookahead tracking and on-the-fly extended-set updates, while standard SABRE uses a normalized front-layer plus extended-layer heuristic with an extended-set size commonly around 20. They provide no Rust implementation details, executable patch, or evidence that these changes improve this benchmark beyond the current 15493.8 score. The evidence also confirms that larger lookahead and broader SABRE search can trade runtime for quality, but the current experiments already show lookahead sizes 16 and 20 reaching the same best score. BFS/layer-based construction and depth-aware weighting therefore remain untested implementation opportunities rather than established improvements; exact dependency-layer semantics, incremental update behavior, and runtime impact still need to be learned or experimentally evaluated.", "status": "scored", "new_documents": 5 }, { "round": 2, "queries": [ { "query": "site:github.com/Qiskit/qiskit/pull/14912/files OR site:github.com/Qiskit/qiskit/blob/main/qiskit/_accelerate \"precomputed_extended_set_logical_pairs\" \"update\" \"layer\" sabre.rs", "intent": "Find the actual Rust implementation or patch for SABRE's on-the-fly, layer-based extended-set maintenance, including how dependency layers and gate ordering are represented and updated after swaps or front-layer progress.", "rationale": "The current best program already matches the strongest tested heuristic configuration, and lookahead sizes 16 and 20 tie. Prior searches established that Qiskit's newer SABRE uses layer-based tracking but did not reveal executable Rust details. Obtaining the exact incremental layer semantics could enable replacing the current topological-order BFS approximation and iteration-index decay with dependency-depth weighting, a concrete untested improvement while avoiding speculative depth heuristics.", "keywords": [ "Qiskit SABRE Rust", "extended set on-the-fly", "layer depth weighting" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [], "kept_mean": null, "assessment": "The new documents reinforce that current Qiskit SABRE development uses layer-based lookahead tracking and on-the-fly extended-set updates, while standard SABRE uses a normalized front-layer plus extended-layer heuristic with an extended-set size commonly around 20. They provide no Rust implementation details, executable patch, or evidence that these changes improve this benchmark beyond the current 15493.8 score. The evidence also confirms that larger lookahead and broader SABRE search can trade runtime for quality, but the current experiments already show lookahead sizes 16 and 20 reaching the same best score. BFS/layer-based construction and depth-aware weighting therefore remain untested implementation opportunities rather than established improvements; exact dependency-layer semantics, incremental update behavior, and runtime impact still need to be learned or experimentally evaluated.", "status": "no_new_documents", "new_documents": 0 }, { "round": 3, "queries": [ { "query": "site:github.com/Qiskit/qiskit/pull/14912/files OR site:github.com/Qiskit/qiskit/blob/main/qiskit/_accelerate \"precomputed_extended_set_logical_pairs\" \"update\" \"layer\" sabre.rs", "intent": "Find the actual Rust implementation or patch for SABRE's on-the-fly, layer-based extended-set maintenance, including how dependency layers and gate ordering are represented and updated after swaps or front-layer progress.", "rationale": "The current best program already matches the strongest tested heuristic configuration, and lookahead sizes 16 and 20 tie. Prior searches established that Qiskit's newer SABRE uses layer-based tracking but did not reveal executable Rust details. Obtaining the exact incremental layer semantics could enable replacing the current topological-order BFS approximation and iteration-index decay with dependency-depth weighting, a concrete untested improvement while avoiding speculative depth heuristics.", "keywords": [ "Qiskit SABRE Rust", "extended set on-the-fly", "layer depth weighting" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [], "kept_mean": null, "assessment": "The new documents reinforce that current Qiskit SABRE development uses layer-based lookahead tracking and on-the-fly extended-set updates, while standard SABRE uses a normalized front-layer plus extended-layer heuristic with an extended-set size commonly around 20. They provide no Rust implementation details, executable patch, or evidence that these changes improve this benchmark beyond the current 15493.8 score. The evidence also confirms that larger lookahead and broader SABRE search can trade runtime for quality, but the current experiments already show lookahead sizes 16 and 20 reaching the same best score. BFS/layer-based construction and depth-aware weighting therefore remain untested implementation opportunities rather than established improvements; exact dependency-layer semantics, incremental update behavior, and runtime impact still need to be learned or experimentally evaluated.", "status": "no_new_documents", "new_documents": 0 } ], "documents": [ { "ref": "evidence_1", "url": "https://github.com/qiskit/qiskit/releases", "title": "Releases · Qiskit/qiskit - GitHub", "domain": "github.com", "excerpt": "Update Sabre extended set on-the-fly (#14912) Use `GateCount` over `Depth` in Clifford+T pipeline (#16218) Move `ParameterVector` to Rust (#16228) Parallelize unitary synthesis (#16275) Use toposort instead of topological\\_op\\_nodes for DAG reconstruction (#15987) Perform ConsolidateBlocks analysis in parallel (#16230) Make Optimize1qGatesDecomposition multithreaded (#15567) Use `np.bitwise_count` in `BitArray.bitcount` (#15836) Use TwoQubitPeepholeOptimization in preset pass managers (#16136) Speedup `SubstitutePi4Rotations` (#16217) Parallelize the CommutationAnalysis pass (#16014) Pivot to foldhash for hash implementation in IndexMap (#15920) Update `PauliProductRotationGate.to_matrix()` from `scipy` to `numpy` (#16016) [...] Fix cache and prediction misses in `Target::qargs` (#16476) (#16479) Update Sabre extended set on-the-fly (#14912) Use `GateCount` over `Depth` in Clifford+T pipeline (#16218) Move `ParameterVector` to Rust (#16228) Parallelize unitary synthesis (#16275) Use toposort instead of topological\\_op\\_nodes for DAG reconstruction (#15987)", "excerpt_truncated": true, "captured_word_count": 228, "rank": 1, "relevance": 0.44116792, "provider": "tavily", "published_date": null, "content_sha256": "bd8be153686664cf7dfbb615f526ff517ba5a2adb78e0b05dc9dcdc7f2e2e768", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 15493.8 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_2", "url": "https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/routing/sabre_swap.py", "title": "qiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main", "domain": "github.com", "excerpt": "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': [...] {{ message }} ### Uh oh! There was an error while loading. Please reload this page. / # sabre\\_swap.py Copy path", "excerpt_truncated": true, "captured_word_count": 355, "rank": 2, "relevance": 0.27682292, "provider": "tavily", "published_date": null, "content_sha256": "6c676ae36113942b7a612bc2a9d35c547f1e4e8ee6fec559a4511ff607fe021f", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 15493.8 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_3", "url": "https://arxiv.org/pdf/2205.10596", "title": "[PDF] arXiv:2205.10596v1 [quant-ph] 21 May 2022", "domain": "arxiv.org", "excerpt": "Algorithm Configuration and Evaluation: In our ex-periment, the weight of the extended layer E is set to 9 0.5, and the size of the layer |E| is 20. The layer size represents the maximum number of two-qubit gates in the layer. The experiments with the SABRE algorithm use the same extended layer size and weight. All the binary values bk are set to 1 to enable all the optimizations. We use the geometric mean to calculate the average ratio of the CNOT gate and depth reduction. The results are the average of ten runs. [...] ∆depthadd is the percentage change in additional circuit depth: ∆depthadd=1 −depthadd(NASSC)/depthadd(SABRE). [...] 60 103 78 −21.18% −30.00% QFT 15-qubits 15 100 407 307 321 221", "excerpt_truncated": true, "captured_word_count": 217, "rank": 3, "relevance": 0.21742928, "provider": "tavily", "published_date": null, "content_sha256": "523f9fc5dc8d39cbc100618567e57c1da2b03ca20be38f70aa8655f26219e6d3", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 15493.8 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_4", "url": "https://github.com/Qiskit/qiskit-terra/issues/5197", "title": "Sabre swap mapper dominated by data copy · Issue #5197 - GitHub", "domain": "github.com", "excerpt": "BFS should be linear runtime if done right. Also the distance calculation should probably be done only for those qubits … is designed with an", "excerpt_truncated": false, "captured_word_count": 25, "rank": 4, "relevance": 0.1310511, "provider": "tavily", "published_date": null, "content_sha256": "53315ae85499b0c1dcf662919080e40814a41c2786403c6e60da45a043b943dd", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 15493.8 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_5", "url": "https://quantum.cloud.ibm.com/docs/tutorials/transpilation-optimizations-with-sabre", "title": "Transpilation optimization with SABRE", "domain": "quantum.cloud.ibm.com", "excerpt": "Output: `pm_1 (4,20,20): 2Q Depth 38, Size 183, Time 0.01s pm_2 (4,200,200): 2Q Depth 36, Size 183, Time 0.15s pm_3 (8,200,200): 2Q Depth 30, Size 158, Time 0.16s pm_star (default + StarPreRouting): 2Q Depth 26, Size 160, Time 0.01s Improvement vs. default (pm_1): pm_2 (4,200,200): 2Q depth +5.3%, size +0.0% pm_3 (8,200,200): 2Q depth +21.1%, size +13.7% pm_star (default + StarPreRouting): 2Q depth +31.6%, size +12.6%` [...] All three modified pass managers produced circuits with lower 2Q depth than the default. The aggressive SABRE configurations (`pm_2` and `pm_3`) trade longer transpilation time for a wider search, while `pm_star` leverages the star structure of the circuit and produces an even shallower result without paying any extra transpilation cost. The exact gains", "excerpt_truncated": true, "captured_word_count": 277, "rank": 5, "relevance": 0.113236144, "provider": "tavily", "published_date": null, "content_sha256": "045118ab0964bd80a3fdaf7e5ce92d259ecdf9987520a9c9ebe3b6b104a209ab", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 15493.8 } ], "kept_rounds": [], "for_solver": false } ], "final_knowledge": "The new documents reinforce that current Qiskit SABRE development uses layer-based lookahead tracking and on-the-fly extended-set updates, while standard SABRE uses a normalized front-layer plus extended-layer heuristic with an extended-set size commonly around 20. They provide no Rust implementation details, executable patch, or evidence that these changes improve this benchmark beyond the current 15493.8 score. The evidence also confirms that larger lookahead and broader SABRE search can trade runtime for quality, but the current experiments already show lookahead sizes 16 and 20 reaching the same best score. BFS/layer-based construction and depth-aware weighting therefore remain untested implementation opportunities rather than established improvements; exact dependency-layer semantics, incremental update behavior, and runtime impact still need to be learned or experimentally evaluated.", "stop_reason": "search_budget_exhausted", "search_attempts": 3, "status": "evaluated", "generation_condition": { "num_generations": 8, "score_target": "best_valid_child_of_n_attempts" }, "predicted_score": null, "excerpt_note": "Excerpts from the saved retrieval, up to 120 words per document. Scores are model predictions before evaluation.", "checkpoint_available": true } }, { "iteration": 66, "gate": "retrieve", "knowledge_state": "The measured experiments show that the current policy is valid and that the changes to decay, endpoint handling, initial layout, and candidate scoring have not produced a reliable improvement: the best observed combined score is 17201.4, while the latest layout-related attempt produced no change. Existing documents establish general SABRE principles, especially that the front-layer distance term should not be weakened by front-layer size and that extended-set weighting can create heuristic hills, but they do not provide the exact current Rust implementation or the precise upstream changes for the relevant Qiskit PRs. The remaining uncertainty is whether the current normalization, lookahead construction, decay application, completion bonus, and initial-layout logic match the intended algorithm and which targeted modification is likely to improve the benchmark.", "reasoning": "Additional evidence would help because the prior attempts have plateaued and the stored search results are mostly irrelevant or high-level. A fresh search for the exact Qiskit Rust route.rs implementation and PR diffs could reveal concrete algorithmic details not available in the existing documents, particularly the intended front-layer/lookahead normalization and on-the-fly extended-set behavior.", "queries": [ { "round": 1, "query": "site:github.com/Qiskit/qiskit/pull/14912/files route.rs SabreSwap basic_weight extended_set_weight SetScaling Constant front_layer decay", "intent": "Determine the exact upstream Rust heuristic formula and scaling rules for the front layer, extended set, and decay in Qiskit's SABRE implementation, especially whether the basic front-layer term must remain unnormalized while only the lookahead term is divided by extended-set size." }, { "round": 2, "query": "site:github.com/Qiskit/qiskit/blob/main/crates/transpiler/src/passes/sabre/route.rs \"with_lookahead\" \"SetScaling::Constant\" \"num_coupling_qubits\"", "intent": "Determine the exact Rust wiring and default heuristic construction for SABRE basic and lookahead weights, especially whether lookahead is set to 0.5 divided by the coupling-map qubit count and how the coupling-qubit count is obtained." }, { "round": 3, "query": "site:github.com/Qiskit/qiskit/blob/main/crates/transpiler/src/passes/sabre/route.rs \"SetScaling::Constant\" \"extended_set_weight\" \"num_coupling_qubits\" \"LayeredExtendedSet\"", "intent": "Verify the latest Rust SABRE implementation details for constructing and scoring the extended set, including the exact coupling-map-qubit normalization, constant scaling, layer updates, score-delta sign, and multiplicative endpoint decay." } ], "sources": [ { "title": "qiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main", "url": "https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/routing/sabre_swap.py", "predicted_score": 17218.2 }, { "title": "SabreSwap (latest version) | IBM Quantum Documentation", "url": "https://quantum.cloud.ibm.com/docs/api/qiskit/qiskit.transpiler.passes.SabreSwap", "predicted_score": 17210.0 } ], "parent_score": 17201.400000000038, "child_score": 17608.200000000026, "best_before": 17201.400000000038, "best_after": 17608.200000000026, "additions": 26, "deletions": 9, "diff": [ "- let gamma = 0.70_f64;", "+ let gamma = 0.60_f64;", "- 0.50", "+ 0.85", "- 0.35", "+ 0.65", "+ }", "+ }", "+ if let Some((last_a, last_b)) = ctx.last_applied_swap() {", "+ for (swap, score) in &mut swap_scores {", "+ if (swap.0 == last_a && swap.1 == last_b)", "+ || (swap.0 == last_b && swap.1 == last_a)", "+ if ctx.swaps_since_progress() < 4 {", "+ *score += 0.20;" ], "changes": "Change 1: Near `/// Scores lookahead gates with geometric decay, p...` (7→8 lines)\nChange 2: Near `// Use a slower geometric decay so the router stil...` (5→3 lines)\nChange 3: Near `fn choose_best_swap(...` (5→8 lines)\nChange 4: Near `let completion_weight = if ctx.swaps_since_progres...` (5→5 lines)\nChange 5: Near `// Apply the standard LightSABRE multiplicative de...` (10→25 lines)", "runtime_web_access": false, "evidence": { "gate": { "knowledge": "The measured experiments show that the current policy is valid and that the changes to decay, endpoint handling, initial layout, and candidate scoring have not produced a reliable improvement: the best observed combined score is 17201.4, while the latest layout-related attempt produced no change. Existing documents establish general SABRE principles, especially that the front-layer distance term should not be weakened by front-layer size and that extended-set weighting can create heuristic hills, but they do not provide the exact current Rust implementation or the precise upstream changes for the relevant Qiskit PRs. The remaining uncertainty is whether the current normalization, lookahead construction, decay application, completion bonus, and initial-layout logic match the intended algorithm and which targeted modification is likely to improve the benchmark.", "reason": "Additional evidence would help because the prior attempts have plateaued and the stored search results are mostly irrelevant or high-level. A fresh search for the exact Qiskit Rust route.rs implementation and PR diffs could reveal concrete algorithmic details not available in the existing documents, particularly the intended front-layer/lookahead normalization and on-the-fly extended-set behavior.", "population": "📊 **State:** The retained population has 40 programs with scores ranging from 17,000.4 to 17,201.4, and the current parent scores 17,201.4, equal to the retained best.\n\n**Key Numbers:**\n• All 40 retained programs have finite scores, with 9 unique numeric scores. \n• The mean score is 17,159.685, the median is 17,197.8, and the population standard deviation is 60.777. \n• The middle 50% spans 17,104.2 to 17,201.4, while the full range is 201.0 points. \n• The recent trace covers 20 retained rows from iteration 40 to iteration 65; 0 rows recorded a global improvement over the preceding retained row.\n\n**Patterns Observed:**\n• Parent selection used 20 slots across 12 unique IDs; the most selected parent appeared 4 times, or 20% of slots. \n• Context selection used 73 slots across 34 unique IDs; the most selected context appeared 5 times, or 26.3% of programs with selection. \n• In the 20-row recent trace, 10 outcomes were unchanged, 5 regressed, and 5 had missing parent scores; observed regressions included −1.2, −6.0, −154.8, −201.0, and −15.0." }, "rounds": [ { "round": 1, "queries": [ { "query": "site:github.com/Qiskit/qiskit/pull/14912/files route.rs SabreSwap basic_weight extended_set_weight SetScaling Constant front_layer decay", "intent": "Determine the exact upstream Rust heuristic formula and scaling rules for the front layer, extended set, and decay in Qiskit's SABRE implementation, especially whether the basic front-layer term must remain unnormalized while only the lookahead term is divided by extended-set size.", "rationale": "The current program still uses SetScaling::Size for both basic and lookahead terms, weakening the front-layer contribution by front-layer size despite the documented Qiskit change that removed this weakening. Previous searches mostly returned irrelevant pages or high-level Python documentation and did not recover the exact route.rs diff. Finding the PR implementation could support a targeted correction rather than further speculative changes to decay, completion bonuses, or layout logic.", "keywords": [ "Qiskit PR 14912", "SABRE Rust route.rs", "SetScaling::Constant", "front-layer normalization", "decay" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [ { "ref": "evidence_1", "score": 17218.2 }, { "ref": "evidence_2", "score": 17210.0 }, { "ref": "evidence_3", "score": 17206.0 }, { "ref": "evidence_4", "score": 17201.4 }, { "ref": "evidence_5", "score": 17201.4 } ], "kept_mean": 17211.399999999998, "assessment": "The new SABRE documentation reinforces that the intended heuristic uses a front-layer mean distance, an extended-set mean distance, and multiplicative endpoint decay using the maximum decay of the swapped qubits. The strongest evidence also gives the relevant defaults: basic weighting with Constant scaling and lookahead weighting of approximately 0.5 divided by the number of coupling-map qubits, rather than the current Size-scaled lookahead. This identifies a concrete likely mismatch in the current implementation and is more actionable than the prior generic SABRE descriptions. The current program additionally contains unvalidated completion bonuses, geometric lookahead ordering, stagnation-dependent weight changes, and custom initial-layout logic, so matching the documented defaults requires a controlled implementation change and benchmark test. The exact Rust PR diff and precise coupling-qubit parameter wiring are still missing. The control-flow issue and data-copy issue are unrelated to the current routing heuristic and provide no expected score improvement.", "status": "scored", "new_documents": 5 }, { "round": 2, "queries": [ { "query": "site:github.com/Qiskit/qiskit/blob/main/crates/transpiler/src/passes/sabre/route.rs \"with_lookahead\" \"SetScaling::Constant\" \"num_coupling_qubits\"", "intent": "Determine the exact Rust wiring and default heuristic construction for SABRE basic and lookahead weights, especially whether lookahead is set to 0.5 divided by the coupling-map qubit count and how the coupling-qubit count is obtained.", "rationale": "The current program still uses Size scaling, geometric ordering, completion bonuses, and adaptive lookahead changes, while the strongest evidence indicates documented defaults use Constant scaling with lookahead weight 0.5 divided by the number of coupling-map qubits. Prior searches found only Python documentation or unrelated GitHub pages, so the exact Rust route.rs implementation and parameter wiring remain unresolved. Finding them would support a controlled, faithful heuristic correction rather than another speculative modification.", "keywords": [ "route.rs", "with_lookahead", "SetScaling::Constant", "num_coupling_qubits" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [ { "ref": "evidence_6", "score": 17201.4 }, { "ref": "evidence_7", "score": 17201.4 }, { "ref": "evidence_8", "score": 17201.4 }, { "ref": "evidence_9", "score": 17201.4 }, { "ref": "evidence_10", "score": 17201.4 } ], "kept_mean": null, "assessment": "The new documents add no relevant SABRE implementation evidence: documents 6–10 are unrelated lookahead search results and should not change the predicted score. The actionable knowledge is already established from the scored evidence: the documented lookahead heuristic uses front-layer and extended-set mean distance, Constant scaling for the lookahead configuration, a lookahead weight of approximately 0.5 divided by the number of coupling-map qubits, and multiplicative endpoint decay using the maximum decay of the swapped endpoints. The current program still mismatches these defaults through Size scaling, an undivided lookahead weight, geometric ordering/decay of extended-set gates, completion bonuses, and stagnation-dependent weight changes. The next attempt should make a controlled heuristic-only change: use unweighted means, Constant scaling, the coupling-qubit-normalized lookahead coefficient, and the documented decay, while disabling the custom bonuses and adaptive modifiers for isolation. Exact Rust PR wiring remains unverified, but no further retrieval is required to define this experiment; the remaining uncertainty is implementation correctness and measured benchmark impact, not missing conceptual knowledge.", "status": "scored", "new_documents": 5 }, { "round": 3, "queries": [ { "query": "site:github.com/Qiskit/qiskit/blob/main/crates/transpiler/src/passes/sabre/route.rs \"SetScaling::Constant\" \"extended_set_weight\" \"num_coupling_qubits\" \"LayeredExtendedSet\"", "intent": "Verify the latest Rust SABRE implementation details for constructing and scoring the extended set, including the exact coupling-map-qubit normalization, constant scaling, layer updates, score-delta sign, and multiplicative endpoint decay.", "rationale": "The conceptual heuristic defaults are known, but the current program still uses Size scaling, geometric extended-set weighting, and custom modifiers, while exact Rust wiring remains unverified. A direct lookup of the current route.rs implementation could reveal the precise behavior needed for an isolated heuristic-only correction and prevent another no-op or incorrectly wired change.", "keywords": [ "route.rs", "LayeredExtendedSet", "SetScaling::Constant", "extended_set_weight" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_11", "evidence_12", "evidence_13", "evidence_14", "evidence_15" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_11", "evidence_12", "evidence_13", "evidence_14", "evidence_15" ], "kept_refs": [ "evidence_1", "evidence_12", "evidence_2" ], "predictions": [ { "ref": "evidence_11", "score": 17201.4 }, { "ref": "evidence_12", "score": 17218.2 }, { "ref": "evidence_13", "score": 17201.4 }, { "ref": "evidence_14", "score": 17201.4 }, { "ref": "evidence_15", "score": 17201.4 } ], "kept_mean": 17218.2, "assessment": "The new documents provide no additional verified Rust implementation details beyond the already established SABRE heuristic defaults. Evidence 12 strongly corroborates the actionable configuration: Constant scaling for the basic and lookahead terms, a lookahead coefficient of 0.5 divided by the number of coupling-map qubits, and the standard multiplicative endpoint decay. Evidence 11 describes a related but non-authoritative implementation with geometric extended-set weighting and a release valve, while evidence 13 is BQSKit documentation and evidence 14 provides only generic SABRE documentation. Evidence 15 confirms common extended-set parameters in a provider integration but does not establish the target Rust wiring. The current program still differs through Size scaling, an undivided lookahead weight, geometric extended-set ordering, completion bonuses, and adaptive stagnation modifiers. No further conceptual retrieval is needed. The remaining uncertainty is untested implementation correctness—especially the coupling-qubit normalization and exact score-sign/decay integration—and the measured benchmark impact of a controlled heuristic-only patch that restores the documented defaults and disables custom bonuses and adaptive modifiers.", "status": "scored", "new_documents": 5 } ], "documents": [ { "ref": "evidence_1", "url": "https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/routing/sabre_swap.py", "title": "qiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main", "domain": "github.com", "excerpt": "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': [...] elif self.heuristic == \"basic\": heuristic = Heuristic(attempt\\_limit=10 \\ num\\_dag\\_qubits).with\\_basic( 1.0, SetScaling.Size ) elif self.heuristic == \"lookahead\": heuristic = ( Heuristic(attempt\\_limit=10 \\", "excerpt_truncated": true, "captured_word_count": 276, "rank": 1, "relevance": 0.73778254, "provider": "tavily", "published_date": null, "content_sha256": "69caebc710f14826cf3e410d64a0fae569e57ee3556b92d0376f98c974724366", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17218.2 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_2", "url": "https://quantum.cloud.ibm.com/docs/api/qiskit/qiskit.transpiler.passes.SabreSwap", "title": "SabreSwap (latest version) | IBM Quantum Documentation", "domain": "quantum.cloud.ibm.com", "excerpt": "> > ‘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∣1​gate∈F∑​D[π(gate.q1​)][π(gate.q2)]+W∗∣E∣1​gate∈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", "excerpt_truncated": true, "captured_word_count": 195, "rank": 2, "relevance": 0.6222074, "provider": "tavily", "published_date": null, "content_sha256": "a74f943e80c07e9fd261e957229ee7605d9c6151ddb5c5956c21639382ef84ce", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17210.0 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_3", "url": "https://quantum.cloud.ibm.com/docs/en/api/qiskit/1.4/qiskit.transpiler.passes.SabreSwap", "title": "SabreSwap (v1.4) | IBM Quantum Documentation", "domain": "quantum.cloud.ibm.com", "excerpt": "> > ‘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 that the front\\_layer. > > Hdecay​=∣F∣1​gate∈F∑​D[π(gate.q1​)][π(gate.q2)]+W∗∣E∣1​gate∈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). > [...] > > Hdecay​=max(decay(SWAP.q1​),decay(SWAP.q2​))∣F∣1​gate∈F∑​D[π(gate.q1​)][π(gate.q2)]+W∗∣E∣1​gate∈E∑​D[π(gate.q1​)][π(gate.q2)] [...] > The search space of", "excerpt_truncated": true, "captured_word_count": 195, "rank": 3, "relevance": 0.61972505, "provider": "tavily", "published_date": null, "content_sha256": "89dc7595805c8a7fbb2a5919385407a73a3ae69a143458bba0acfe2030ec8c2e", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17206.0 } ], "kept_rounds": [ 1, 2 ], "for_solver": false }, { "ref": "evidence_4", "url": "https://github.com/Qiskit/qiskit/issues/16857", "title": "`SabreSwap` can violate loop layout invariants when break_loop or continue_loop bypasses restoration SWAPs · Issue #16857 · Qiskit/qiskit · GitHub", "domain": "github.com", "excerpt": "The router therefore reasons as though: `layout(block exit) = layout(block entry)` while an early-exit execution can instead produce: `layout(break exit) != layout(block entry) layout(continue edge) != layout(block entry)` The enclosing routing state nevertheless continues under the assumption that the entry layout has been restored. Later gates and measurements can therefore be applied to the wrong physical qubits. [...] Relevant implementation: `route_control_flow_block` `RoutingResult::rebuild_onto` `BreakLoop` `ContinueLoop` `final_swaps` The rebuilding logic emits the restoration SWAPs only after all routed operations in the block: This establishes the expected layout on the normal fall-through edge of the block, but not on an early-exit edge. According to the public semantics: `BreakLoopOp` `ContinueLoopOp` Consequently, restoration SWAPs placed after either operation are not executed on that runtime path.", "excerpt_truncated": true, "captured_word_count": 205, "rank": 4, "relevance": 0.16898064, "provider": "tavily", "published_date": null, "content_sha256": "17065a4a474f3e02d1b24d60e67bab0a2e085c3cadb2937be5b82fbe3ed7ae64", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_5", "url": "https://github.com/Qiskit/qiskit-terra/issues/5197", "title": "Sabre swap mapper dominated by data copy · Issue #5197", "domain": "github.com", "excerpt": "Oct 8, 2020 — Operating system: What is the current behavior? Running Sabre on a QV circuit over 20 qubits shows that data copying is the current bottleneck:.Read more", "excerpt_truncated": false, "captured_word_count": 29, "rank": 5, "relevance": 0.09715906, "provider": "tavily", "published_date": null, "content_sha256": "2e311bf39bc35c6236089d1fe38b0e3124d26afe65641869583df8a5970242ed", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_6", "url": "https://vi-control.net/community/threads/libraries-with-lookahead-functionality.160386", "title": "Libraries with 'lookahead' functionality?", "domain": "vi-control.net", "excerpt": "Feb 2, 2025 — Modern Scoring Strings and Tokyo Scoring Stings both have a lookahead mode, where when activated all quantised midi plays back pretty much ...Read more", "excerpt_truncated": false, "captured_word_count": 28, "rank": 1, "relevance": 0.13884693, "provider": "tavily", "published_date": null, "content_sha256": "9bfc08a981fb5719ac8cc7e139553c03ccee645de3f662ff2ede4aafc17afa05", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_7", "url": "https://proandroiddev.com/animations-with-lookahead-in-jetpack-compose-60423fe0d1a7", "title": "Animations with Lookahead in Jetpack Compose", "domain": "proandroiddev.com", "excerpt": "Mar 11, 2024 — Lookahead is a potent API within Jetpack Compose that, when utilized correctly, enables the creation of stunning and highly performant ...Read more", "excerpt_truncated": false, "captured_word_count": 26, "rank": 2, "relevance": 0.13856693, "provider": "tavily", "published_date": null, "content_sha256": "678e9469e98752e1631eb99130557ce1346f3dd57085d078cec588181783d04e", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_8", "url": "https://arxiv.org/abs/2506.19830", "title": "[2506.19830] Scaling Speculative Decoding with Lookahead Reasoning", "domain": "arxiv.org", "excerpt": "archive # Computer Science > Machine Learning # Title:Scaling Speculative Decoding with Lookahead Reasoning | | | --- | | Subjects: | Machine Learning (cs.LG); Computation and Language (cs.CL) | | Cite as: | arXiv:2506.19830 [cs.LG] | | | (or arXiv:2506.19830v1 [cs.LG] for this version) | | | Focus to learn more arXiv-issued DOI via DataCite | ## Submission history ## Access Paper: ### Current browse context: ### References & Citations ## BibTeX formatted citation ### Bookmark BibSonomy Reddit # Bibliographic and Citation Tools # Code, Data and Media Associated with this Article # Demos # Recommenders and Search Tools # arXivLabs: experimental projects with community collaborators [...] arXivLabs is a framework that allows collaborators to develop and share new", "excerpt_truncated": true, "captured_word_count": 187, "rank": 3, "relevance": 0.13065127, "provider": "tavily", "published_date": null, "content_sha256": "324051e259a79b644fac161634f8d5e5304b2fe4510f4a68b534977cfd77d3cb", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_9", "url": "https://arxiv.org/abs/2601.15214", "title": "[2601.15214] A Complete Propositional Dynamic Logic for Regular Expressions with Lookahead", "domain": "arxiv.org", "excerpt": "archive # Computer Science > Logic in Computer Science # Title:A Complete Propositional Dynamic Logic for Regular Expressions with Lookahead | | | --- | | Comments: | Long version of a paper accepted at FoSSaCS 2026 | | Subjects: | Logic in Computer Science (cs.LO); Formal Languages and Automata Theory (cs.FL) | | Cite as: | arXiv:2601.15214 [cs.LO] | | | (or arXiv:2601.15214v2 [cs.LO] for this version) | | | Focus to learn more arXiv-issued DOI via DataCite | | Related DOI: | Focus to learn more DOI(s) linking to related resources | ## Submission history ## Access Paper: license icon ### Current browse context: ### References & Citations ## BibTeX formatted citation ### Bookmark BibSonomy Reddit # Bibliographic", "excerpt_truncated": true, "captured_word_count": 233, "rank": 4, "relevance": 0.10821744, "provider": "tavily", "published_date": null, "content_sha256": "b888396ef0568b3207d8c3bee9601685d1fd52cbbb0430f8b3fec3694aa1890b", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_10", "url": "https://substrate.stackexchange.com/questions/12108/invalid-transaction-on-parachain-with-lookahead-collator", "title": "Invalid transaction on parachain with lookahead collator", "domain": "substrate.stackexchange.com", "excerpt": "Dec 15, 2024 — an off-chain worker constant sends tx to parachain are reported as invalid. rather lookahead consensus - it could be mitigated by delayed-best-", "excerpt_truncated": false, "captured_word_count": 26, "rank": 5, "relevance": 0.10007563, "provider": "tavily", "published_date": null, "content_sha256": "e0b9842f140e305f56b7fd52f061eee28175b13e86891ad601d7d856a0484a30", "rounds": [ 2 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_11", "url": "https://pkg.go.dev/github.com/splch/goqu/transpile/routing", "title": "routing package - github.com/splch/goqu/transpile/routing - Go Packages", "domain": "pkg.go.dev", "excerpt": "0.5) // geometric weight for extended set layers (default 0.5) ReleaseValveThreshold int // SWAPs before release valve fires (default 10numQubits, -1 disables) // SWAPs before release valve fires (default 10numQubits, -1 disables) [...] Trials int // number of random initial layouts to try (default 20) // number of random initial layouts to try (default 20) BidirectionalIters int // forward+backward iterations per trial (default 4) // forward+backward iterations per trial (default 4) Seed uint64 // random seed; nil = non-deterministic // random seed; nil = non-deterministic Parallelism int // max concurrent trials (default GOMAXPROCS) // max concurrent trials (default GOMAXPROCS) DecayDelta float64 // decay increment per SWAP (default 0.001) // decay increment per SWAP (default 0.001) ExtendedSetDepth int // BFS layers", "excerpt_truncated": true, "captured_word_count": 150, "rank": 1, "relevance": 0.35797194, "provider": "tavily", "published_date": null, "content_sha256": "116811f844d5334cbd5c2131df8d14d1687bda958e7a923c5b3495f26a82a613", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_12", "url": "https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/routing/sabre_swap.py", "title": "qiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main", "domain": "github.com", "excerpt": "elif self.heuristic == \"basic\": heuristic = Heuristic(attempt\\_limit=10 \\ num\\_dag\\_qubits).with\\_basic( 1.0, SetScaling.Size ) elif self.heuristic == \"lookahead\": heuristic = ( Heuristic(attempt\\_limit=10 \\ num\\_dag\\_qubits) .with\\_basic(1.0, SetScaling.Constant) .with\\_lookahead([0.5 / num\\_coupling\\_qubits], SetScaling.Constant) ) elif self.heuristic == \"decay\": heuristic = ( Heuristic(attempt\\_limit=10 \\ num\\_dag\\_qubits) .with\\_basic(1.0, SetScaling.Constant) .with\\_lookahead([0.5 / num\\_coupling\\_qubits], SetScaling.Constant) .with\\_decay(0.001, 5) ) else: raise TranspilerError(f\"Heuristic {self.heuristic} not recognized.\") disjoint\\_utils.require\\_layout\\_isolated\\_to\\_component(dag, self.target) [...] 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", "excerpt_truncated": true, "captured_word_count": 228, "rank": 2, "relevance": 0.30309245, "provider": "tavily", "published_date": null, "content_sha256": "4cca6be316b7acb6433c78bf30a54534d071345add40de09e43a0912e10d7a4d", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 17218.2 } ], "kept_rounds": [ 3 ], "for_solver": true }, { "ref": "evidence_13", "url": "https://bqskit.readthedocs.io/en/latest/source/autogen/bqskit.passes.PAMLayoutPass.html", "title": "PAMLayoutPass — BQSKit documentation", "domain": "bqskit.readthedocs.io", "excerpt": "`int` `GeneralizedSabreAlgorithm` decay\\_reset\\_on\\_gate (`bool`) – See `GeneralizedSabreAlgorithm` for info. (Default: True) `bool` `GeneralizedSabreAlgorithm` extended\\_set\\_size (`int`) – See `GeneralizedSabreAlgorithm` for info. (Default: 20) `int` `GeneralizedSabreAlgorithm` extended\\_set\\_weight (`float`) – See `GeneralizedSabreAlgorithm` for info. (Default: 0.5) `float` `GeneralizedSabreAlgorithm` Attributes | | | --- | | `name` | The name of the pass. | `name` `name` The name of the pass. Methods", "excerpt_truncated": false, "captured_word_count": 58, "rank": 3, "relevance": 0.24998283, "provider": "tavily", "published_date": null, "content_sha256": "290ed363f0d5da233810097b70aba392d2ff3bc425bfe1d8fb01909a304ff369", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_14", "url": "https://quantum.cloud.ibm.com/docs/api/qiskit/2.0/qiskit.transpiler.passes.SabreSwap", "title": "SabreSwap (v2.0) | IBM Quantum Documentation", "domain": "quantum.cloud.ibm.com", "excerpt": "This is weighted by some amount EXTENDED_SET_WEIGHT (W) to signify that upcoming gates are less important that the front_layer.", "excerpt_truncated": false, "captured_word_count": 19, "rank": 4, "relevance": 0.23784177, "provider": "tavily", "published_date": null, "content_sha256": "b61a7d978a8c6ef805d88f51787015db56e98503a6360491c4b5265a3ea064d2", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_15", "url": "https://xn--thequantumlnd-lfb.de/docs/backends.html", "title": "Backends — Qiskit QRyd Provider documentation", "domain": "xn--thequantumlnd-lfb.de", "excerpt": "+ `seed_compiler` (`int`\"), default: None): A seed for the random number generator of the compiler. + `use_extended_set` (`bool`\"), default: True): Whether the SABRE algorithm uses the extended set of gates. + `use_reverse_traversal` (`bool`\"), default: True): Whether SABRE uses the reverse traversal technique to update the initial mapping. + `extended_set_size` (`int`\"), default: 5): Size of the extended set of gates used by SABRE. + `extended_set_weight` (`float`\"), default: 0.5): Weight of the extended set of gates used by SABRE. + `reverse_traversal_iterations` (`int`\"), default: 2): The number of times SABRE is run back and forth. [...] Backends View page source # Backends class qiskit\\_qryd\\_provider.QRydBackend(\\\\kwargs)(_modules/qiskit_qryd_provider/qryd_backend.html#QRydBackend) : Super class for accessing the emulator of the QRydDemo consortium. All backends are derived from this class, which", "excerpt_truncated": true, "captured_word_count": 267, "rank": 5, "relevance": 0.15338454, "provider": "tavily", "published_date": null, "content_sha256": "3958c0b9cc004b888c51c73127878b0f7c4afa2e132341e89c4b049766e7168d", "rounds": [ 3 ], "predictions": [ { "round": 3, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false } ], "final_knowledge": "The new documents provide no additional verified Rust implementation details beyond the already established SABRE heuristic defaults. Evidence 12 strongly corroborates the actionable configuration: Constant scaling for the basic and lookahead terms, a lookahead coefficient of 0.5 divided by the number of coupling-map qubits, and the standard multiplicative endpoint decay. Evidence 11 describes a related but non-authoritative implementation with geometric extended-set weighting and a release valve, while evidence 13 is BQSKit documentation and evidence 14 provides only generic SABRE documentation. Evidence 15 confirms common extended-set parameters in a provider integration but does not establish the target Rust wiring. The current program still differs through Size scaling, an undivided lookahead weight, geometric extended-set ordering, completion bonuses, and adaptive stagnation modifiers. No further conceptual retrieval is needed. The remaining uncertainty is untested implementation correctness—especially the coupling-qubit normalization and exact score-sign/decay integration—and the measured benchmark impact of a controlled heuristic-only patch that restores the documented defaults and disables custom bonuses and adaptive modifiers.", "stop_reason": "search_budget_exhausted", "search_attempts": 3, "status": "evaluated", "generation_condition": { "num_generations": 8, "score_target": "best_valid_child_of_n_attempts" }, "predicted_score": null, "excerpt_note": "Excerpts from the saved retrieval, up to 120 words per document. Scores are model predictions before evaluation.", "checkpoint_available": true } }, { "iteration": 77, "gate": "retrieve", "knowledge_state": "The strongest measured result came from the earlier heuristic changes, while subsequent variants using geometric lookahead, stagnation scaling, topology-dependent weighting, completion bonuses, and multiplicative decay produced mixed or worse scores. Existing documents establish the standard SABRE normalization and the motivation for LightSABRE-style progress escapes, but they do not provide the exact Rust implementation or behavioral details of the upstream on-the-fly extended-set update associated with Qiskit PR #14912. The current program still rebuilds the extended set from the front layer on every swap-selection call and uses index-based geometric weighting, so the likely next improvement requires understanding layered/dependency-aware extended-set maintenance and its precise interaction with scoring. That information is not sufficiently available in the retained documents.", "reasoning": "Additional evidence would help because the unresolved extended-set construction and successor-layer ordering are central to the next plausible optimization. Prior searches mostly returned generic SABRE documentation, release notes, or irrelevant results rather than the actual patch, so a fresh targeted search for the upstream PR diff, Rust route implementation, and related tests is warranted.", "queries": [ { "round": 1, "query": "raw.githubusercontent.com/Qiskit/qiskit/main/crates/transpiler/src/passes/sabre/route.rs LayeredExtendedSet on-the-fly extended set update", "intent": "Find the current upstream Rust implementation and exact update algorithm for maintaining the layered SABRE extended set as front-layer gates are executed, including successor dependency counts, layer replenishment, ordering, and scoring integration." }, { "round": 2, "query": "\"Update Sabre extended set on-the-fly (#14912)\" Rust route.rs diff LayeredExtendedSet successor replenishment", "intent": "Find the exact Rust implementation or patch for PR #14912, especially how the layered extended set is maintained and replenished as front-layer gates execute, including predecessor-count updates, successor ordering, and score normalization." }, { "round": 3, "query": "\"Update Sabre extended set on-the-fly (#14912)\" Rust route.rs diff LayeredExtendedSet successor replenishment", "intent": "Find the exact Rust implementation or patch for PR #14912, especially how the layered extended set is maintained and replenished as front-layer gates execute, including predecessor-count updates, successor ordering, and score normalization." } ], "sources": [ { "title": "qiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main", "url": "https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/routing/sabre_swap.py", "predicted_score": 17201.4 }, { "title": "transpiler (latest version) | IBM Quantum Documentation", "url": "https://quantum.cloud.ibm.com/docs/api/qiskit/transpiler", "predicted_score": 17201.4 }, { "title": "Transforming Quantum Circuits using Qiskit's Transpiler with ...", "url": "https://www.youtube.com/watch?v=MvX5OUK-tbE", "predicted_score": 17201.4 } ], "parent_score": 17201.400000000038, "child_score": 17875.800000000032, "best_before": 17784.600000000006, "best_after": 17875.800000000032, "additions": 30, "deletions": 3, "diff": [ "- let gamma = 0.70_f64;", "+ let gamma = 0.60_f64;", "+ let topology = ctx.topology();", "+ let average_degree = if topology.num_qubits() == 0 {", "+ } else {", "+ 2.0 * topology.num_edges() as f64 / topology.num_qubits() as f64", "+ let topology_factor = if average_degree < 2.5 {", "+ 0.55", "+ } else if average_degree < 3.0 {", "+ 0.80", "+ } else {", "+ * topology_factor", "- 0.50", "+ 0.65" ], "changes": "Change 1: Near `let gamma = 0.70_f64;...` (2→4 lines)\nChange 2: Near `let lookahead_weight = if extended_set.is_empty() ...` (16→37 lines)\nChange 3: Near `let completion_weight = if ctx.swaps_since_progres...` (5→9 lines)\nChange 4: Near `// Apply standard SABRE multiplicative decay to re...` (8→14 lines)", "runtime_web_access": false, "evidence": { "gate": { "knowledge": "The strongest measured result came from the earlier heuristic changes, while subsequent variants using geometric lookahead, stagnation scaling, topology-dependent weighting, completion bonuses, and multiplicative decay produced mixed or worse scores. Existing documents establish the standard SABRE normalization and the motivation for LightSABRE-style progress escapes, but they do not provide the exact Rust implementation or behavioral details of the upstream on-the-fly extended-set update associated with Qiskit PR #14912. The current program still rebuilds the extended set from the front layer on every swap-selection call and uses index-based geometric weighting, so the likely next improvement requires understanding layered/dependency-aware extended-set maintenance and its precise interaction with scoring. That information is not sufficiently available in the retained documents.", "reason": "Additional evidence would help because the unresolved extended-set construction and successor-layer ordering are central to the next plausible optimization. Prior searches mostly returned generic SABRE documentation, release notes, or irrelevant results rather than the actual patch, so a fresh targeted search for the upstream PR diff, Rust route implementation, and related tests is warranted.", "population": "📊 **State:** The retained population contains **40** fully scored programs with scores from **16,892.4** to **17,784.6**, while the current parent scores **17,201.4**, which is **583.2** below the retained best.\n\n**Key Numbers:**\n• Score spread: mean **17,226.2**, median **17,201.4**, and population standard deviation **151.6**; the total score range is **892.2** points. \n• Score concentration: **12** exact unique scores occur among **40** programs; the interquartile range is **3.6** points, from **17,197.8** to **17,201.4**. \n• Recent trajectory: across **20** trace entries from iterations **47–76**, **5** entries improved relative to their parent and **4** regressed. \n• Recent high points: scores reached **17,608.2** at iteration **66**, **17,672.4** at iteration **71**, and **17,784.6** at iteration **75**.\n\n**Patterns Observed:**\n• Parent selection used **20** slots across **15** unique programs; the most-selected parent appeared **3** times, or **15%** of parent slots. \n• Context selection used **63** slots across **34** unique programs; the most-selected context appeared **5** times, or **27.8%** of context slots. \n• Recent outcomes included **7** unchanged entries, **4** missing-parent-score entries, and **4** regressed entries; the largest recent improvement was **+680.4**, while the largest regression was **−294.0**." }, "rounds": [ { "round": 1, "queries": [ { "query": "raw.githubusercontent.com/Qiskit/qiskit/main/crates/transpiler/src/passes/sabre/route.rs LayeredExtendedSet on-the-fly extended set update", "intent": "Find the current upstream Rust implementation and exact update algorithm for maintaining the layered SABRE extended set as front-layer gates are executed, including successor dependency counts, layer replenishment, ordering, and scoring integration.", "rationale": "The current program rebuilds the extended set from the front layer on every swap decision and lacks the dependency-aware layered maintenance introduced by Qiskit PR 14912. The retrieved searches mostly returned release notes, Python SABRE documentation, or irrelevant results, while the best recent variants improved through heuristic tuning but still leave this implementation gap. The upstream route.rs source should provide concrete data structures and invariants that can be ported safely, potentially improving both routing quality and repeated-call overhead without further speculative weight changes.", "keywords": [ "LayeredExtendedSet", "on-the-fly extended set", "route.rs", "Qiskit PR 14912" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_4", "evidence_5" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [ { "ref": "evidence_1", "score": 17201.4 }, { "ref": "evidence_2", "score": 17201.4 }, { "ref": "evidence_3", "score": 17201.4 }, { "ref": "evidence_4", "score": 17201.4 }, { "ref": "evidence_5", "score": 17201.4 } ], "kept_mean": 17201.4, "assessment": "The new documents provide no actionable implementation details for the current Rust SABRE router. The first document only reiterates standard front-layer/lookahead scoring, while the remaining documents are generic Qiskit documentation, tutorials, or explanatory material. They confirm that SABRE is an enhanced, high-performing routing method, but do not reveal the upstream on-the-fly extended-set data structure, layer semantics, successor replenishment rules, or exact PR #14912 changes. The current program already implements the documented standard normalization, geometric lookahead, completion incentives, and decay variants; these documents therefore do not justify a predicted improvement. The key missing knowledge remains the precise Rust source or patch for layered/on-the-fly extended-set maintenance and its interaction with scoring. Once that implementation is obtained, it still needs to be tested as a focused variant against the current best rather than combined with additional heuristic changes.", "status": "scored", "new_documents": 5 }, { "round": 2, "queries": [ { "query": "\"Update Sabre extended set on-the-fly (#14912)\" Rust route.rs diff LayeredExtendedSet successor replenishment", "intent": "Find the exact Rust implementation or patch for PR #14912, especially how the layered extended set is maintained and replenished as front-layer gates execute, including predecessor-count updates, successor ordering, and score normalization.", "rationale": "The current program rebuilds a static extended set on every swap and already contains standard SABRE scoring, decay, completion incentives, and geometric lookahead. Recent improvements came from heuristic tuning, but the best unresolved opportunity is the precise upstream on-the-fly layered-set implementation. Earlier searches found only release notes and generic Python documentation, so this query targets the PR title together with the Rust file and likely data-structure terminology while avoiding another generic SABRE search.", "keywords": [ "Qiskit PR 14912", "LayeredExtendedSet", "on-the-fly extended set", "route.rs" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [ { "ref": "evidence_6", "score": 17201.4 }, { "ref": "evidence_7", "score": 17201.4 }, { "ref": "evidence_8", "score": 17201.4 }, { "ref": "evidence_9", "score": 17201.4 }, { "ref": "evidence_10", "score": 17201.4 } ], "kept_mean": null, "assessment": "The new documents provide no actionable implementation details for the current Rust SABRE router. The first document only reiterates standard front-layer/lookahead scoring, while the remaining documents are generic Qiskit documentation, tutorials, or explanatory material. They confirm that SABRE is an enhanced, high-performing routing method, but do not reveal the upstream on-the-fly extended-set data structure, layer semantics, successor replenishment rules, or exact PR #14912 changes. The current program already implements the documented standard normalization, geometric lookahead, completion incentives, and decay variants; these documents therefore do not justify a predicted improvement. The key missing knowledge remains the precise Rust source or patch for layered/on-the-fly extended-set maintenance and its interaction with scoring. Once that implementation is obtained, it still needs to be tested as a focused variant against the current best rather than combined with additional heuristic changes.", "status": "partial", "new_documents": 5 }, { "round": 3, "queries": [ { "query": "\"Update Sabre extended set on-the-fly (#14912)\" Rust route.rs diff LayeredExtendedSet successor replenishment", "intent": "Find the exact Rust implementation or patch for PR #14912, especially how the layered extended set is maintained and replenished as front-layer gates execute, including predecessor-count updates, successor ordering, and score normalization.", "rationale": "The current program rebuilds a static extended set on every swap and already contains standard SABRE scoring, decay, completion incentives, and geometric lookahead. Recent improvements came from heuristic tuning, but the best unresolved opportunity is the precise upstream on-the-fly layered-set implementation. Earlier searches found only release notes and generic Python documentation, so this query targets the PR title together with the Rust file and likely data-structure terminology while avoiding another generic SABRE search.", "keywords": [ "Qiskit PR 14912", "LayeredExtendedSet", "on-the-fly extended set", "route.rs" ], "resources": [ "github", "docs" ] } ], "retrieved_refs": [ "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "candidate_refs": [ "evidence_1", "evidence_2", "evidence_3", "evidence_6", "evidence_7", "evidence_8", "evidence_9", "evidence_10" ], "kept_refs": [ "evidence_1", "evidence_2", "evidence_3" ], "predictions": [], "kept_mean": null, "assessment": "The new documents provide no actionable implementation details for the current Rust SABRE router. The first document only reiterates standard front-layer/lookahead scoring, while the remaining documents are generic Qiskit documentation, tutorials, or explanatory material. They confirm that SABRE is an enhanced, high-performing routing method, but do not reveal the upstream on-the-fly extended-set data structure, layer semantics, successor replenishment rules, or exact PR #14912 changes. The current program already implements the documented standard normalization, geometric lookahead, completion incentives, and decay variants; these documents therefore do not justify a predicted improvement. The key missing knowledge remains the precise Rust source or patch for layered/on-the-fly extended-set maintenance and its interaction with scoring. Once that implementation is obtained, it still needs to be tested as a focused variant against the current best rather than combined with additional heuristic changes.", "status": "no_new_documents", "new_documents": 0 } ], "documents": [ { "ref": "evidence_1", "url": "https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/routing/sabre_swap.py", "title": "qiskit/qiskit/transpiler/passes/routing/sabre_swap.py at main", "domain": "github.com", "excerpt": "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': [...] {{ message }} ### Uh oh! There was an error while loading. Please reload this page. / # sabre\\_swap.py Copy path", "excerpt_truncated": true, "captured_word_count": 356, "rank": 1, "relevance": 0.55275756, "provider": "tavily", "published_date": null, "content_sha256": "3901c9d562e7713c45913e0aad4d14c2b209860bc25b92b5ac69fe810bc4c6cb", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17201.4 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_2", "url": "https://quantum.cloud.ibm.com/docs/api/qiskit/transpiler", "title": "transpiler (latest version) | IBM Quantum Documentation", "domain": "quantum.cloud.ibm.com", "excerpt": "from qiskit.transpiler.passes import (from qiskit. transpiler. passes import ( UnitarySynthesis, UnitarySynthesis, Collect2qBlocks, Collect2qBlocks, ConsolidateBlocks, ConsolidateBlocks, UnitarySynthesis, UnitarySynthesis, Unroll3qOrMore, Unroll3qOrMore,))from qiskit.transpiler import PassManager, StagedPassManager from qiskit. transpiler import PassManager, StagedPassManager basis_gates = [\"rx\", \"ry\", \"rxx\"] basis_gates = [\"rx\", \"ry\", \"rxx\"]init = PassManager([UnitarySynthesis(basis_gates, min_qubits=3), Unroll3qOrMore()]) init = PassManager([UnitarySynthesis(basis_gates, min_qubits = 3), Unroll3qOrMore()])translate = PassManager(translate = PassManager( [ [ Collect2qBlocks(), Collect2qBlocks(), ConsolidateBlocks(basis_gates=basis_gates), ConsolidateBlocks(basis_gates [...] Note The built-in set of available plugins for each stage is part of Qiskit’s public API, and subject to all the stability guarantees. This includes the high-level logical effects of that method (for example, `routing_method=\"sabre\"` will always use a Sabre-derived algorithm). The exact internal construction of the `PassManager` representing the stage is not, however; the order of passes might", "excerpt_truncated": true, "captured_word_count": 292, "rank": 2, "relevance": 0.47957736, "provider": "tavily", "published_date": null, "content_sha256": "a3f4797ef01b03416b301b3a08afef2eaae0ddeaa529510b75dffa4e0c3eea79", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17201.4 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_3", "url": "https://www.youtube.com/watch?v=MvX5OUK-tbE", "title": "Transforming Quantum Circuits using Qiskit's Transpiler with ...", "domain": "www.youtube.com", "excerpt": "at the end we apply the layout which just takes whatever layout we found and transforms the circuit to take that into account. So let's look at what this transform does. So if you look at the layout stage what we had coming into it from the in it stage uh we have the circuit and there are no cubits there are no physical cubits assigned from the target. Um but when we run the layout stage the biggest change here is that we've uh reordered the cubits and we've assigned them each a cubit index from the actual uh target that's specified. So in this case I believe I picked the Torino IBM Torino as the target. So um", "excerpt_truncated": true, "captured_word_count": 463, "rank": 3, "relevance": 0.4556594, "provider": "tavily", "published_date": null, "content_sha256": "981806a4a68c6b5f05077ad53d2d20f7cd24a89e87dbaf1349dda316a9d5b106", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17201.4 } ], "kept_rounds": [ 1, 2, 3 ], "for_solver": true }, { "ref": "evidence_4", "url": "https://qiskit.qotlabs.org/docs/tutorials/compilation-methods-for-hamiltonian-simulation-circuits", "title": "Compilation methods for Hamiltonian simulation circuits", "domain": "qiskit.qotlabs.org", "excerpt": "#### Qiskit transpiler with SABRE The Qiskit transpiler uses the SABRE (SWAP-based BidiREctional heuristic search) algorithm to optimize circuit layout and routing. SABRE focuses on minimizing SWAP gates and their impact on circuit depth while respecting hardware connectivity constraints. It is a general-purpose method that provides a good balance between performance and compilation time. For more details, see ( The advantages and parameter exploration of SABRE are covered in-depth in a separate tutorial. #### AI-powered transpiler", "excerpt_truncated": false, "captured_word_count": 76, "rank": 4, "relevance": 0.3966996, "provider": "tavily", "published_date": null, "content_sha256": "da5384a0fa14351a975f1506b3e9bece68d4c7e875ad3552c49c50d58c11eb80", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_5", "url": "https://quantum.cloud.ibm.com/docs/guides/transpile", "title": "Introduction to transpilation | IBM Quantum Documentation", "domain": "quantum.cloud.ibm.com", "excerpt": "A central component of the Qiskit SDK, the transpiler is designed for modularity and extensibility. Its main use is to write new circuit transformations (known as transpiler passes), and combine them with other existing passes, greatly reducing the depth and complexity of quantum circuits. Which passes are chained together and in which order has a major effect on the final outcome. This pipeline is determined by the `PassManager` and `StagedPassManager` objects. The `StagedPassManager` orchestrates the execution of one or more `PassManagers` and determines the order in which they are executed, while the `PassManager` object is merely a collection of one or more passes. Think of the `StagedPassManager` as the conductor in an orchestra, the `PassManagers` as the different instrument", "excerpt_truncated": false, "captured_word_count": 119, "rank": 5, "relevance": 0.39564833, "provider": "tavily", "published_date": null, "content_sha256": "2e1fa43fb2f3c0c9db1015a761a879ed9d7d1249e408345325c1e5804e711f67", "rounds": [ 1 ], "predictions": [ { "round": 1, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_6", "url": "https://www.corrosionhour.com/rust-update-2nd-september-2022", "title": "RUST Update 2nd September 2022 - RUST", "domain": "www.corrosionhour.com", "excerpt": "> > And so now, bang! Small wooden boxes have 18 slots, and large ones have 48! A surprise, to be sure, but a welcome one. > > In other changes, the coaling tower was switched up a bit; it now has a tradesman’s entrance at the top where the suspended bridge is. You still need a keycard to get in this way. It’s just a little bit sneakier and good for making a sharp exit if you need to. > > There are new reclaim and drone marketplace models, as shown previously because the ones we’ve been used to were just placeholders and SUBJECT TO CHANGE. > > In quality of life, the UI when harvesting will show a", "excerpt_truncated": true, "captured_word_count": 400, "rank": 1, "relevance": 0.29182827, "provider": "tavily", "published_date": null, "content_sha256": "a2687e252e6868ac3a46a5480da78ae60fc9efdd159d3e9595c038d242c4841e", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_7", "url": "https://git.zx2c4.com/wireguard-rs/commit?id=92dbb4c46a5651afb8f92375e0ed154673929eeb", "title": "Clean dependencies and imports - wireguard-rs - Rust implementation of WireGuard", "domain": "git.zx2c4.com", "excerpt": "Title: Clean dependencies and imports - wireguard-rs - Rust implementation of WireGuard peer.update\\_only { + log::trace!(\"flush peer, add peer\"); config.add\\_peer(&peer.public\\_key); } - for (ip, masklen) in &peer.allowed\\_ips { - config.add\\_allowed\\_ip(&peer.public\\_key, \\*ip, \\*masklen); + for (ip, cidr) in &peer.allowed\\_ips { + log::trace!(\"flush peer, add allowed\\_ips : {}/{}\", ip.to\\_string(), cidr); + config.add\\_allowed\\_ip(&peer.public\\_key, \\*ip, \\*cidr); } if let Some(psk) = peer.preshared\\_key { + log::trace!(\"flush peer, set preshared\\_key {}\", hex::encode(psk)); config.set\\_preshared\\_key(&peer.public\\_key, psk); } if let Some(secs) = peer.persistent\\_keepalive\\_interval { + log::trace!(\"flush peer, set persistent\\_keepalive\\_interval {}\", secs); config.set\\_persistent\\_keepalive\\_interval(&peer.public\\_key, secs); } if let Some(version) = peer.protocol\\_version { + log::trace!(\"flush peer, set protocol\\_version {}\", version); if version == 0 || version > config.get\\_protocol\\_version() { return Some(ConfigError::UnsupportedProtocolVersion); } } if let Some(endpoint) = peer.endpoint { + log::trace!(\"flush peer,", "excerpt_truncated": true, "captured_word_count": 434, "rank": 2, "relevance": 0.18457669, "provider": "tavily", "published_date": null, "content_sha256": "bee27cf70750daf2541e6cc26b0da1099a8238e9de8099cc45e14728461afe89", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_8", "url": "https://www.scalemates.com/kits/wolfpack-wp32081-f-86f-sabre-update-set--1229969", "title": "F-86F Sabre Update set, Wolfpack WP32081", "domain": "www.scalemates.com", "excerpt": "plastic modeling database | stash manager # F-86F Sabre Update set ## for Kinetic ## Wolfpack | No. WP32081 | 1:32 ### Facts Brand: : Wolfpack Title: : F-86F Sabre Update set for Kinetic Number: : WP32081 Scale: : 1:32 Type: : Detail set Barcode : 4589913276338 (JAN) Topic: : North American F-86 Sabre » Jets (Aircraft) ### Designed for K3203\")K3201\")K3202 2009\") ### Marketplace ##### Online shops Logo BNA Model World AUD 23.96 AU BRL 91.08In stock »Logo Sprue Brothers Models USD 20.99 US BRL 111.88In stock »Logo HobbyLink Japan ¥ 1140 JP BRL 44.77Out of stock » Note: Prices and availability are indicative only. Always check that the product actually matches! Alternative SKUs for Wolfpack WP32081: WOLFPACK WP32081 |", "excerpt_truncated": true, "captured_word_count": 194, "rank": 3, "relevance": 0.13503832, "provider": "tavily", "published_date": null, "content_sha256": "8f35a42de29dfd7a343c62de8b3f437396257d537b63be6fb7ec88066f0af2c0", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_9", "url": "https://git.zx2c4.com/wireguard-rs/commit?id=74e576a9c21b0de451e0588428fbbb99b24eb074", "title": "Fixed inbound job bug (add to sequential queue) - wireguard-rs - Rust implementation of WireGuard", "domain": "git.zx2c4.com", "excerpt": "Title: Fixed inbound job bug (add to sequential queue) - wireguard-rs - Rust implementation of WireGuard body.state.protector.lock().update(header.f\\_counter.get()) { @@ -136,13 +144,9 @@ fn sequential>( // update endpoint \\*peer.endpoint.lock() = body.endpoint.take(); - // calculate length of IP packet + padding - let length = packet.len() - SIZE\\_TAG; - log::debug!(\"inbound worker: plaintext length = {}\", length); - // check if should be written to TUN let mut sent = false; - if length > 0 { + if packet.len() > 0 { sent = match peer.device.inbound.write(&packet[..]) { Err(e) => { log::debug!(\"failed to write inbound packet to TUN: {:?}\", e); diff --git a/src/wireguard/router/mod.rs b/src/wireguard/router/mod.rs index 3243b88..bccb0a9 100644 --- a/src/wireguard/router/mod.rs +++ b/src/wireguard/router/mod.rs @@ -7,6 +7,7 @@ mod messages; mod outbound; mod peer; mod pool;", "excerpt_truncated": true, "captured_word_count": 512, "rank": 4, "relevance": 0.13326876, "provider": "tavily", "published_date": null, "content_sha256": "7f700f8bfd0ed07c70e15808d50ddc143153dbb7c8a34c4309a5fe2972bddec2", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false }, { "ref": "evidence_10", "url": "https://fly.io/docs/rust", "title": "Rust on Fly.io · Fly Docs", "domain": "fly.io", "excerpt": "you need to set up, run, and manage production Rust apps on Fly.io. These documents also identify some common problems you may encounter and provide some pointers on how to resolve them. [...] Skip to content Need a Logo? View Our Brand Assets Pricing Support Sign In Sign Up [...] ## The Basics The Basics covers everything you need to set up, run, and manage production Rust apps on Fly.io. These documents also identify some common problems you may encounter and provide some pointers on how to resolve them. or Open in ChatGPT Report an issue or edit this page on GitHub", "excerpt_truncated": false, "captured_word_count": 102, "rank": 5, "relevance": 0.13239136, "provider": "tavily", "published_date": null, "content_sha256": "837556ed18d0a14a834d195d2bd4d5320da5c3bd494d474908c7396b00ed4dcb", "rounds": [ 2, 3 ], "predictions": [ { "round": 2, "score": 17201.4 } ], "kept_rounds": [], "for_solver": false } ], "final_knowledge": "The new documents provide no actionable implementation details for the current Rust SABRE router. The first document only reiterates standard front-layer/lookahead scoring, while the remaining documents are generic Qiskit documentation, tutorials, or explanatory material. They confirm that SABRE is an enhanced, high-performing routing method, but do not reveal the upstream on-the-fly extended-set data structure, layer semantics, successor replenishment rules, or exact PR #14912 changes. The current program already implements the documented standard normalization, geometric lookahead, completion incentives, and decay variants; these documents therefore do not justify a predicted improvement. The key missing knowledge remains the precise Rust source or patch for layered/on-the-fly extended-set maintenance and its interaction with scoring. Once that implementation is obtained, it still needs to be tested as a focused variant against the current best rather than combined with additional heuristic changes.", "stop_reason": "search_budget_exhausted", "search_attempts": 3, "status": "evaluated", "generation_condition": { "num_generations": 8, "score_target": "best_valid_child_of_n_attempts" }, "predicted_score": null, "excerpt_note": "Excerpts from the saved retrieval, up to 120 words per document. Scores are model predictions before evaluation.", "checkpoint_available": true } } ], "history": { "points": [ { "iteration": 0, "candidate_score": 6387.000000000058, "best_score": 6387.000000000058, "gate": "unrecorded" }, { "iteration": 1, "candidate_score": 6497.999999999985, "best_score": 6497.999999999985, "gate": "retrieve" }, { "iteration": 2, "candidate_score": 6565.799999999974, "best_score": 6565.799999999974, "gate": "retrieve" }, { "iteration": 3, "candidate_score": 6957.000000000015, "best_score": 6957.000000000015, "gate": "retrieve" }, { "iteration": 4, "candidate_score": 6957.000000000015, "best_score": 6957.000000000015, "gate": "retrieve" }, { "iteration": 5, "candidate_score": 11325.600000000006, "best_score": 11325.600000000006, "gate": "retrieve" }, { "iteration": 6, "candidate_score": 11325.600000000006, "best_score": 11325.600000000006, "gate": "retrieve" }, { "iteration": 7, "candidate_score": 15174.00000000003, "best_score": 15174.00000000003, "gate": "retrieve" }, { "iteration": 8, "candidate_score": 15341.399999999994, "best_score": 15341.399999999994, "gate": "retrieve" }, { "iteration": 9, "candidate_score": 15493.800000000017, "best_score": 15493.800000000017, "gate": "retrieve" }, { "iteration": 10, "candidate_score": 11602.800000000003, "best_score": 15493.800000000017, "gate": "retrieve" }, { "iteration": 11, "candidate_score": 15493.800000000017, "best_score": 15493.800000000017, "gate": "retrieve" }, { "iteration": 12, "candidate_score": 15493.800000000017, "best_score": 15493.800000000017, "gate": "retrieve" }, { "iteration": 13, "candidate_score": 16871.40000000001, "best_score": 16871.40000000001, "gate": "retrieve" }, { "iteration": 14, "candidate_score": 11325.600000000006, "best_score": 16871.40000000001, "gate": "retrieve" }, { "iteration": 15, "candidate_score": 17197.800000000032, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 16, "candidate_score": 15512.400000000023, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 17, "candidate_score": 16285.800000000076, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 18, "candidate_score": 16457.399999999994, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 19, "candidate_score": 16912.800000000003, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 20, "candidate_score": 17041.20000000001, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 21, "candidate_score": 6936.60000000002, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 22, "candidate_score": 17197.800000000032, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 23, "candidate_score": 16927.800000000017, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 24, "candidate_score": 17197.800000000032, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 25, "candidate_score": 15512.400000000023, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 26, "candidate_score": 17197.800000000032, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 27, "candidate_score": 17197.800000000032, "best_score": 17197.800000000032, "gate": "retrieve" }, { "iteration": 28, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 29, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 30, "candidate_score": 17041.20000000001, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 31, "candidate_score": 15512.400000000023, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 32, "candidate_score": 17197.800000000032, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 33, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 34, "candidate_score": 17197.800000000032, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 35, "candidate_score": 17041.20000000001, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 36, "candidate_score": 15512.400000000023, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 37, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 38, "candidate_score": 16872.60000000002, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 39, "candidate_score": 15512.400000000023, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 40, "candidate_score": 17104.199999999997, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 41, "candidate_score": 16353.00000000003, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 42, "candidate_score": 17200.20000000004, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 43, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 44, "candidate_score": 17197.800000000032, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 45, "candidate_score": 17104.199999999997, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 46, "candidate_score": 15493.800000000017, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 47, "candidate_score": 17191.800000000032, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 48, "candidate_score": 17046.60000000005, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 49, "candidate_score": 16285.800000000076, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 50, "candidate_score": 17104.199999999997, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 51, "candidate_score": 16896.0, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 52, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 53, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 54, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 55, "candidate_score": 17104.199999999997, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 56, "candidate_score": 16912.800000000003, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 57, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 58, "candidate_score": 17000.400000000023, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 59, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 60, "candidate_score": 17104.199999999997, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 61, "candidate_score": 16369.800000000017, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 62, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 63, "candidate_score": 17201.400000000038, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 64, "candidate_score": 17186.40000000001, "best_score": 17201.400000000038, "gate": "lookup" }, { "iteration": 65, "candidate_score": 17104.199999999997, "best_score": 17201.400000000038, "gate": "retrieve" }, { "iteration": 66, "candidate_score": 17608.200000000026, "best_score": 17608.200000000026, "gate": "retrieve" }, { "iteration": 67, "candidate_score": 16895.400000000038, "best_score": 17608.200000000026, "gate": "retrieve" }, { "iteration": 68, "candidate_score": 17489.400000000052, "best_score": 17608.200000000026, "gate": "lookup" }, { "iteration": 69, "candidate_score": 16965.000000000015, "best_score": 17608.200000000026, "gate": "retrieve" }, { "iteration": 70, "candidate_score": 17198.40000000001, "best_score": 17608.200000000026, "gate": "lookup" }, { "iteration": 71, "candidate_score": 17672.400000000023, "best_score": 17672.400000000023, "gate": "retrieve" }, { "iteration": 72, "candidate_score": 17201.400000000038, "best_score": 17672.400000000023, "gate": "retrieve" }, { "iteration": 73, "candidate_score": 17200.20000000004, "best_score": 17672.400000000023, "gate": "retrieve" }, { "iteration": 74, "candidate_score": 17201.400000000038, "best_score": 17672.400000000023, "gate": "retrieve" }, { "iteration": 75, "candidate_score": 17784.600000000006, "best_score": 17784.600000000006, "gate": "retrieve" }, { "iteration": 76, "candidate_score": 16892.399999999994, "best_score": 17784.600000000006, "gate": "retrieve" }, { "iteration": 77, "candidate_score": 17875.800000000032, "best_score": 17875.800000000032, "gate": "retrieve" }, { "iteration": 78, "candidate_score": 18160.20000000004, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 79, "candidate_score": 17201.400000000038, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 80, "candidate_score": 17784.600000000006, "best_score": 18160.20000000004, "gate": "noop" }, { "iteration": 81, "candidate_score": 16173.599999999991, "best_score": 18160.20000000004, "gate": "lookup" }, { "iteration": 82, "candidate_score": 17218.800000000032, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 83, "candidate_score": 17201.400000000038, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 84, "candidate_score": 17201.400000000038, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 85, "candidate_score": 17784.600000000006, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 86, "candidate_score": 16077.0, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 87, "candidate_score": 17218.800000000032, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 88, "candidate_score": 18160.20000000004, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 89, "candidate_score": 17201.400000000038, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 90, "candidate_score": 17784.600000000006, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 91, "candidate_score": 17682.00000000003, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 92, "candidate_score": 17218.800000000032, "best_score": 18160.20000000004, "gate": "noop" }, { "iteration": 93, "candidate_score": 17201.400000000038, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 94, "candidate_score": 17201.400000000038, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 95, "candidate_score": 16087.800000000003, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 96, "candidate_score": 16936.200000000026, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 97, "candidate_score": 17218.800000000032, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 98, "candidate_score": 17194.800000000032, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 99, "candidate_score": 17201.400000000038, "best_score": 18160.20000000004, "gate": "retrieve" }, { "iteration": 100, "candidate_score": 17784.600000000006, "best_score": 18160.20000000004, "gate": "retrieve" } ], "trace_sha256": "8d512aaa255fc014b8f47fcec657f850d1a380976a3eda01bc2fde2a76f604f9", "score_label": "Search-time evaluator score ↑", "note": "Best-so-far envelope of recorded, non-migrant programs. If multiple programs share an iteration, the highest recorded score is used. Missing iterations are not invented." }, "run_fingerprint": "1d40a453690ba168cd7c0b3ab434fd4eadba54444d46681c2a1f0c43be5c23bb", "last_iteration": 100 }