PaperlayerView exact revision on arXiv

Source-linked AI summary

EvoSignal: LLM-Guided Evolutionary Design of Modular Traffic Signal Control Programs

Leizhen Wang, Peibo Duan, Zhenlin Qin, Yancheng Ling, Jian Xu, Yue Wang, Hao Wang, Zhenliang Ma

arXiv:2610.09563v1cs.LG

TL;DR

Traffic signal control must adapt to changing demand and network conditions, while manual strategy design is difficult and direct LLM phase selection incurs recurring inference costs and latency. EvoSignal evolves modular control programs using traffic knowledge and performance feedback. Its default program reduces waiting time against the 20 reference controllers in all five scenarios, and a travel-time-and-queue-focused program transfers among the top three across them.

  • Problem

    Designing effective traffic rules for varying demands, network interactions, and objectives is challenging; direct LLM phase selection also incurs recurring inference costs and leaves rules embedded in model parameters.

    Source: §1 · pp. 1–2

  • Method

    EvoSignal evolves modular executable control programs using multiple initial strategies, simulation performance feedback, traffic diagnostics, and strategy summaries.

    Source: §1 · pp. 2–3

  • Results

    The default program reduces waiting time by 16.8–49.2% relative to the lowest waiting time among 20 reference controllers in each of five scenarios; the TT–QL program ranks in the top three on every metric across all five.

    Source: §6 · p. 20

  • Takeaways & Limitations

    The selected program controls signals directly from traffic observations without online LLM inference, and the TT–QL program transfers unchanged across the evaluated scenarios while remaining top three on each metric.

    Source: §6 · p. 20

    Because revisions can change several interacting rules at once, a higher program score does not identify which change helps, under what conditions, or whether it transfers to another program.

    Source: §5.4 · p. 20

Abstract

from arXiv · show

Effective traffic signal control (TSC) requires policies that respond to changing traffic demand and network conditions while meeting different control objectives. However, adapting existing strategies often involves repeated manual design and adjustment, making it difficult to systematically explore better control rules for a target network. Large language models (LLMs) can automate this process, but directly using them to select signal phases leaves decision rules embedded in black-box models and incurs recurring inference costs and latency. This paper formulates TSC as a modular program design problem and proposes EvoSignal, an LLM-guided evolutionary framework using traffic knowledge and performance feedback. The modular representation separates traffic feature extraction, local phase prioritization, and optional network-based priority adjustment. Starting from several established strategies, EvoSignal improves programs through feedback on congestion and signal operation, retaining strategies with different performance trade-offs. The resulting programs operate without online LLM inference. Simulation experiments across five scenarios on two real-world road networks show that the selected default EvoSignal program reduces waiting time by 16.8--49.2\% relative to the lowest waiting time achieved by the 20 conventional, reinforcement learning-based, and LLM-based baselines in each scenario. A program prioritizing travel time and queue length outperforms all 20 baselines on all three metrics in the search scenario and remains among the top three on each metric when transferred unchanged to the other four scenarios. These findings support automated design of inspectable control programs that transfer across the evaluated road networks and traffic demands.Code is available at https://github.com/georgewanglz2019/EvoSignal.

1 Introduction

Traffic signal control must respond to changing demand and network interactions, yet designing and adapting effective rules for different scenarios remains challenging. EvoSignal uses LLM-guided evolution to produce modular, inspectable programs, with transferred programs ranking among the top three on all metrics in four other scenarios.

Motivation

  • Different networks, demands, and objectives complicate control, while interactions between intersections can shift congestion downstream.The paper identifies four design challenges: modularizing decisions, diversifying initial strategies, diagnosing traffic behavior, and retaining alternatives across objectives.Source: §1 · pp. 1–2

Contributions

  • EvoSignal formulates traffic signal control as modular program design, separating feature extraction, local phase prioritization, and optional network-based priority adjustment.The explicit interfaces support targeted revision and inspection of control logic.Source: §1 · pp. 2–3
  • EvoSignal combines multiple initial strategies, traffic-performance diagnostics, and reusable strategies with different objective trade-offs to guide LLM-based program revision.The selected program then determines signal phases directly from traffic observations.Source: §1 · pp. 2–3

Evaluation

  • A program evolved in one scenario transfers unchanged to four others and ranks among the top three on travel time, queue length, and waiting time against 20 reference controllers.The evaluation covers five scenarios on two real-world road networks and compares conventional, RL-based, and LLM-based controllers.Source: §1 · p. 3

2 Related Work

Related work spans rule-based, learned, and language-model-driven traffic control, as well as LLM-guided program evolution. The section motivates traffic-specific program design that combines local decisions, network conditions, multiple strategies, and different objectives.

2 Related Work

  • The review compares methods by their traffic responsiveness, decision-rule transparency, and computational requirements.It groups the literature into conventional TSC, RL-based TSC, LLM-based TSC, and LLM-guided program design and evolution.Source: §2 · p. 3

2.1 Conventional Traffic Signal Control

  • Conventional controllers use explicit engineering rules and modest computation, but extending predefined rules to complex interactions or changing objectives requires further engineering.Examples include fixed-time design, adaptive systems such as SCOOT, and pressure-based control [5].Source: §2.1 · p. 3

2.2 Reinforcement Learning-Based Traffic Signal Control

  • RL learns traffic-responsive policies and coordination, but requires interaction data and optimization, while neural rules can be difficult to inspect or modify and may need adaptation beyond training conditions.The section reviews approaches including MARLIN-ATSC, PressLight, and MetaLight.Source: §2.2 · pp. 3–4

2.3 LLM-Based Traffic Signal Control

  • LLM-based signal controllers use traffic context and language reasoning for phase decisions, but repeated inference adds online cost and latency, and verbal rationales do not expose the complete neural decision rule.Compact models can reduce the burden, but resource requirements remain a deployment consideration.Source: §2.3 · p. 4

2.4 LLM-Guided Program Design and Evolution

  • LLM-guided evolution revises executable programs using performance feedback, but general frameworks leave traffic-specific representation and evaluation guidance to application designers.Prior traffic work includes single-intersection fixed-time design [16] and interpretable skills with structured feedback [17]; EvoSignal combines modular programs, multiple strategies, diagnostics, and trade-off reuse.Source: §2.4 · p. 5

3 Methodology

The methodology treats traffic signal control as the design of executable programs with modular decision logic and specified performance objectives. EvoSignal evolves these programs using multiple seeds, simulation feedback, diagnostics, and reusable strategies.

3.1.1 Traffic observations and phase decisions

  • An executable policy maps intersection observations to phase priorities and selects a phase, with the same fixed program responding to changing conditions at each intersection.Inputs can include phase state, elapsed time, movement queues, downstream information, history, and shared information.Source: §3.1.1 · pp. 5–6

3.1.2 3M: Modular control program representation

  • The 3M representation separates traffic feature extraction, local phase prioritization, and optional network-based priority adjustment through explicit interfaces.The modules compute features z and context c, base phase scores q, and adjustments r that can modify local preferences.Source: §3.1.2 · pp. 6–7

3.1.3 Program design objective

  • Programs are evaluated on minimized travel time, queue length, and waiting time, combined into a bounded scalar score using fixed objective weights.The design variables are module implementations, while interfaces and phase selection remain specified; transfer to other networks or demands is evaluated separately.Source: §3.1.3 · p. 7

3.2 EvoSignal: LLM-Guided Evolutionary Search

  • EvoSignal revises candidate code within the 3M interfaces, evaluates it in simulation, and uses performance records, traffic diagnostics, and strategy summaries to guide further revisions.The procedure selects parents and references from a program database; the selected code remains fixed during control execution.Source: §3.2 · p. 8, §3.2.1 · pp. 8–9

3.3 Multi-init: Initialization with Multiple Control Strategies

  • Multi-init seeds the search with established or LLM-generated strategies that express complementary control ideas through the same interfaces.Seeds are evaluated under the same scenario and objective weights before evolution attempts begin.Source: §3.3 · p. 9

3.4 SPA: Simulation Performance Analyzer

  • SPA converts recorded traffic behavior into diagnostics and revision suggestions because aggregate scores alone do not show queue locations or phase-demand mismatches.It examines selection frequency, switching, queue changes, and congestion; subsequent evaluation determines whether an edit improves performance.Source: §3.4 · pp. 9–10

3.5 PSA: Pareto Strategy Archive

  • PSA retains module summaries and measured outcomes from recent successful programs, including nondominated strategies and some dominated records, for reuse in later revisions.Its retained set represents recent trade-offs rather than the complete search history; parent and final-program selection still follow database rules and the scalar score.Source: §3.5 · p. 10

4 Experiments

The experiments evaluate evolved control programs across two real-world networks and five observed-demand scenarios, comparing their control performance, transfer, search behavior, and objective trade-offs. The selected programs improve waiting time against reference controllers, transfer across the evaluated scenarios, and show that performance depends on the design objective.

4.1.1 Traffic Networks and Simulation Environment

  • Experiments use Jinan’s 12-intersection Dongfeng and Hangzhou’s 16-intersection Gudang networks, with observed-demand scenarios J1–J3 and H1–H2.Controllers select among four phases every 30 seconds; a phase change incurs a five-second yellow transition within that interval.Source: §4.1.1 · p. 11

4.1.2 Compared Methods

  • Comparisons include 20 conventional, RL-based, and LLM-based reference controllers, two LLM-guided evolution frameworks, and four component ablations.Three EvoSignal configurations use different objectives or source scenarios; the fixed programs are compared by traffic metrics rather than scores from different objectives.Source: §4.1.2 · pp. 12–13

4.1.3 Evolution Settings and Evaluation Protocol

  • The main search starts from 11 programs, runs 200 evolution iterations, and selects the highest source-scenario combined-score program across independent runs for unchanged evaluation on all five scenarios.Primary framework and ablation comparisons use three runs; framework progress axes show iteration or generation budget, not elapsed time.Source: §4.1.3 · pp. 13–14

4.2 Traffic Control Performance of Selected Evolved Programs

  • 16.78–49.24%: the selected default EvoSignal program reduces waiting time versus the best of 20 references across all five scenarios.On H2, it also outperforms all 20 references on travel time, queue length, and waiting time.Source: §4.2 · p. 14

4.3 Transfer across Road Networks and Traffic Demands

  • Both TT–QL programs rank among the top three on every metric across all five scenarios, while heavier-demand tests show the advantages do not extend uniformly.The programs are reused without further search or target-specific tuning; the reported transfer scenarios share an observation structure and four-phase interface.Source: §4.3 · pp. 14–15

4.4 Evolution Performance and Component Ablations

  • Across three independent runs, EvoSignal has the highest mean final best score (0.397314 ± 0.000489) and lowest variation among frameworks; full EvoSignal likewise has the highest mean final score and lowest SD among four ablations.Without 3M, the controller has a lower mean score and substantially greater variation than full EvoSignal; without Multi-init, mean final score is lowest at 0.392190 ± 0.005428. Without SPA, mean final score is 0.394508 and SD is 0.002684.Source: §4.4 · pp. 15, 16, 18

4.2 Traffic Control Performance of Selected Evolved Programs

  • Relative to Maxpressure, the default program improves all three metrics in every scenario, with waiting-time reductions of 17.10–55.62%.The TT–QL program further improves travel time and queue length on J1–J3 and H1, but its waiting time on J2 is 0.39% higher than Maxpressure.Source: §4.2 · p. 14, Figure 4 · p. 17

4.5 Influence of Objective Weights

  • On J1, the TT–QL program lowers travel time from 277.74 to 271.85 seconds and queue length from 163.29 to 155.53 vehicles, while waiting time rises from 34.31 to 41.98 seconds.Across J2, J3, and H1, TT–QL also has lower travel time and queue length but higher waiting time; on H2, the default program performs better on all three metrics.Source: §4.5 · p. 18

5 Program Analysis and Discussion

The analysis traces how selected programs encode different phase-priority rules, then discusses modular design’s role in inspectable control and limits in interpretation and attribution.

5.1 Control Rules of the Selected Programs

  • Both J1 programs extract phase features, prioritize locally, and optionally adjust priorities using network information before selecting the highest-priority phase.Their shared inputs include pressure, waiting and approaching vehicles, and recent service history; their priority calculations differ.Source: §5.1 · pp. 18–19, Table 4 · p. 19
  • The explicit program representation makes decision rules inspectable, but aggregate results do not isolate each rule’s contribution.Appendix C gives feature definitions, calculations, conditions, coefficients, and service-history updates.Source: §5.1 · p. 19

5.2 How Existing Strategies Are Revised

  • Evolution retained the fairness-aware seed’s service-history idea while adding pressure, waiting and approaching demand, and downstream conditions to the default rule.Later revisions strengthened compensation for long service age combined with many waiting vehicles.Source: §5.2 · p. 19
  • A recorded revision example shows the LLM changing feature extraction and phase scoring through SEARCH/REPLACE edits, but does not establish that each edit improves every metric.The records link prompt inputs, responses, saved code, and evaluation results.Source: §5.2 · p. 19

5.3 Implications for Traffic Control Design

  • The design components address separate needs: 3M separates processing and prioritization, Multi-init supplies established starting ideas, SPA highlights traffic conditions, and PSA supports strategy reuse.The resulting source code remains available for inspection.Source: §5.3 · pp. 19–20
  • The selected program uses explicit rules to choose phases from current observations without online LLM inference, concentrating LLM computation in offline design.The experiments demonstrate traffic performance and traceable rule changes.Source: §5.3 · p. 20

5.4 Limitations and Future Directions

  • Strategy summaries and the use of diagnostics and archived strategies during revision depend on LLM interpretation, which may overlook observations or produce behavior unlike its explanation.The authors suggest post-training and explicit strategy-selection mechanisms as directions for future work.Source: §5.4 · p. 20
  • Because one revision may introduce several interacting changes, whole-program scores cannot identify which change helps, under what conditions, or whether it transfers.The authors propose testing individual changes, their interactions, and reuse in other controllers.Source: §5.4 · p. 20

6 Conclusion

EvoSignal uses modular executable programs and feedback-guided evolution to design traffic signal controllers. On evaluated real-world networks, its selected programs show lower waiting time than reference controllers and strong cross-scenario rankings.

6 Conclusion

  • EvoSignal combines modular executable policies, multiple initial strategies, traffic diagnostics, and reuse of strategies with different performance trade-offs to guide code revision.The selected program responds to traffic observations without online LLM inference.Source: §6 · p. 20
  • WT fell by 16.8–49.2% relative to the lowest WT achieved by the 20 reference controllers in each of five scenarios.The default EvoSignal program was evaluated on real-world road networks and traffic demand.Source: §6 · p. 20
  • The TT–QL program outperformed all references on all three metrics in J1 and ranked within the top three on every metric across all five scenarios without revision.The program was searched in one scenario and transferred unchanged to the others.Source: §6 · p. 20
  • EvoSignal achieved higher mean search scores and lower variation than the evaluated LLM-guided program evolution frameworks.The authors conclude that explicit control-rule suitability should be assessed against intended objectives and operating conditions.Source: §6 · p. 20

Appendix A. Search Statistics

Appendix A reports J1 default-objective search statistics, including initial scores, gains during evolution, and comparisons with and without PSA.

Appendix A. Search Statistics

  • Table 5 reports final best J1 scores under the default objective; SD is sample standard deviation, and “Without 3M” uses the archived monolithic controller and corresponding search guidance.Source: Table 5 · p. 25, Appendix A · p. 25
  • 0.385995 with Multi-init versus 0.384187 with the single seed was the mean best initial score; subsequent evolution added 0.011319 versus 0.008002, respectively.Single-seed runs also contained fewer valid evolutionary records, a consideration when interpreting final performance.Source: Appendix A · p. 25
  • 0.395385 with PSA versus 0.394389 without it was the average best-so-far score over configured search steps.Source: Appendix A · p. 25

Appendix B. Complete Evaluations of Fixed Programs

Across eight scenarios, the fixed programs show that EvoSignal’s advantages on the five main scenarios do not extend uniformly to heavier demand. The selected default and TT–QL programs use distinct feature aggregation and phase-scoring rules.

Appendix B. Complete Evaluations of Fixed Programs

  • Each fixed program is evaluated once per scenario, and the reported SDs describe variation between programs.The appendix reports fixed-program results across the eight scenarios in Table 1.Source: Appendix B · p. 25
  • Default EvoSignal has lower mean WT than TT–QL on J-high (197.02 versus 332.66 s), H-high (81.09 versus 312.72 s), and J-24h (26.77 versus 29.29 s).ShinkaEvolve has lower means on all three metrics under both high-flow profiles; on J-24h, default EvoSignal has slightly lower TT and QL, with similar WT.Source: Appendix B · p. 25, Table 6 · p. 26

Appendix C. Feature Extraction and Priority Rules of the Selected Programs

  • The selected programs’ equations summarize feature extraction, priority adjustment, and service-history updates under finite, nonnegative vehicle observations and an admissible current phase.Their coefficients are program constants, distinct from search-objective weights.Source: Appendix C · p. 27

C.1 Shared Notation and Feature Aggregation

  • The shared notation aggregates supplied efficient-pressure, waiting, approaching, and upstream/downstream vehicle features into intermediate per-phase demand terms, not complete priorities.The evaluation makes decisions every 30 seconds after initialization; service-age variables count controller calls rather than seconds.Source: §C.1 · p. 27

C.2 Default EvoSignal

  • Default EvoSignal combines demand with downstream attenuation and service-age compensation, then adjusts priorities using network pressure and neighboring load.Its service age counts calls since a phase was last requested, not vehicle waiting time.Source: §C.2 · pp. 27–28

C.3 EvoSignal (TT–QL)

  • TT–QL updates service history from the observed active phase before scoring and bounds its service-age bonus at eight before downstream attenuation.It also reduces the current-phase priority when fewer than two approaching vehicles are observed; during a yellow transition it returns the stored action.Source: §C.3 · pp. 28–29

C.4 Revision History of the Default Program

The default program’s revisions improve all three reported traffic metrics relative to its fairness-aware seed, although improvement is not monotonic. The appendix also illustrates a separate diagnostics-guided edit and describes which computations the modular program exposes for revision.

C.4 Revision History of the Default Program

  • Relative to the fairness-aware seed, the final default program reduces TT by 2.24%, QL by 5.52%, and WT by 7.91%.The highest-scoring evaluation at iteration 156 uses code identical to iteration 144; iteration 130 improves TT and QL but worsens WT and the combined score.Source: §C.4 · p. 29
  • A separate SPA-guided revision adds efficient pressure and downstream information, reducing TT from 286.51 to 280.68 s, QL from 175.17 to 167.19 vehicles, and WT from 37.20 to 34.18 s.Its parent report identifies peak congestion in the third quarter and a 95.5% switching rate.Source: §C.4 · p. 29

D.1 Editable Program Structure

  • Evolution revises computations within M1–M3 while retaining their interfaces and the prescribed phase-selection operation.M1 can change feature aggregation and history construction; M2 can change coefficients and phase-scoring rules; M3 can change network-context corrections.Source: §D.1 · p. 30

D.2 Input: Task and Traffic Diagnostics

The revision example combines traffic diagnostics with retained-strategy information to guide an LLM’s code edit. The resulting child improves all three traffic metrics relative to its parent, while the recorded example does not isolate either input’s causal contribution.

D.2 Input: Task and Traffic Diagnostics

  • The prompt components map to the method notation, and its full input also includes parent code and reference programs.The excerpt focuses on task guidance, SPA, and PSA.Source: §D.2 · p. 30, Table 8 · p. 31

D.3 Input: Strategy Memory; Output: Revision Rationale

  • The supplied strategy summary describes an earlier strategy with a score exceeding the parent’s current score; its displayed iter -1 is a missing identifier.The archive reports 71 evaluated strategies, eight on the Pareto front, and advises studying non-dominated solutions for trade-offs.Source: §D.3 · p. 32, PSA: one retained strategy · p. 32

PSA: one retained strategy

  • The retained Pareto-front strategy uses efficient pressure, waiting and approaching vehicles, downstream counts, lane occupancy, and a linear anti-starvation bonus.Its reported rule reduces current-phase priority after six steps; the saved summary’s iter -1 is not the revision’s iteration.Source: PSA: one retained strategy · p. 32, §D.3 · p. 32

LLM response: stated revision and planned edits

  • The LLM response proposes simplifying M1 and replacing M2 with the archived strategy’s local-priority rule, declining to implement every SPA suggestion.Its rationale favors the simpler rule because the archive records a stronger score, but those explanations are model-reported rather than measured outcomes.Source: LLM response: stated revision and… · p. 32

Recorded SEARCH/REPLACE format (M2 excerpt)

  • The recorded revision uses SEARCH/REPLACE edits, with the complete method on each side; displayed omissions are not part of the executable edit.The intermediate revision is distinct from the two final programs analyzed in Appendix C.Source: §D.4 · p. 33, Recorded SEARCH/REPLACE format (M2… · p. 33

After: the replacement priority computation

  • The replacement priority computation uses efficient pressure, waiting vehicles, approaching vehicles, downstream counts, occupancy, and service age before adjusting the current phase’s priority.The recorded constants are STARVATION_THRESHOLD = 4 and MAX_GREEN_STEPS = 6.Source: After: the replacement priority… · p. 34
  • All three traffic metrics improve relative to the parent, and the resulting score recovers the level of an earlier archived strategy.The appendix presents this as a documented example of strategy reuse and program revision, not an estimate of SPA or PSA’s causal contribution.Source: After: the replacement priority… · p. 34, Table 9 · p. 34

Appendix E. Objective-Weight Analysis and Additional Views

The two J1 searches yield different trade-offs depending on the objective weights used to score the selected programs. The objective-space views show those searches in three dimensions and pairwise projections over wider display ranges.

Appendix E. Objective-Weight Analysis and Additional Views

  • Under default weights, TT–QL gains about 0.00514 on combined TT and QL but costs 0.01483 on WT versus default EvoSignal; under TT–QL weights, the gain is 0.00755 and the cost 0.00198, reversing their ranking.Across evolved candidates, median TT and QL decrease under TT–QL weights while median WT increases; the statistics describe the two recorded searches.Source: Appendix E · p. 35
  • Figure 8 presents three-objective and pairwise projections over wider display ranges than Figure 7, retaining selected programs and empirical non-dominated points in view.Figure 8 uses TT 270–290 s, QL 150–185 vehicles, and WT 30–60 s display limits.Source: Figure 8 · p. 35, Appendix E · p. 36
  • The searches contain 197 and 200 valid records, respectively; their non-dominated fronts are computed jointly for three objectives or separately for each metric pair.The fronts do not establish global Pareto optimality.Source: Appendix E · p. 35

Appendix F. Implementation Details and Hyperparameters

Appendix F reports core evolution settings and describes the initial programs’ modular feature-extraction and phase-prioritization structure.

Appendix F. Implementation Details and Hyperparameters

  • Table 10 summarizes core settings for archived main EvoSignal runs, including configurations that enable or ablate 3M, Multi-init, SPA, and PSA.Objective weights for the three evaluated configurations are defined in Section 4.1.2.Source: Appendix F · p. 36, Table 10 · p. 36

F.1 Initial Programs and Feature Examples

  • The 11 initial programs were LLM-assisted, tested for execution, and designed around complementary control ideas rather than as complete reproductions of classical controllers.Their names indicate design inspiration, and they use the same 3M interfaces.Source: §F.1 · pp. 36–37, Table 11 · p. 37
  • M1 transforms movement-level observations into phase-selection features, combining queue pressure, waiting-vehicle counts, and moving-vehicle demand.The feature vector can also include phase features, movement-level information, and current signal state; shared features may come from different decision steps because intersections update sequentially.Source: §F.1 · pp. 36–37
  • M2 assigns each phase a base score using a weighted combination of features, while evolution may replace the starting linear rule with nonlinear, conditional, or history-dependent rules.The pressure–demand seed uses mean phase-pressure features from available neighbors for network adjustment; setting its initial gate to zero removes the additive effect while the scaffold still computes r.Source: §F.1 · pp. 37–38

F.2 Database Records and Evolution Updates

The appendix describes how evaluated programs and seeds are recorded and updated, how SPA statistics guide inspection, and how PSA summaries are stored and retrieved.

F.2 Database Records and Evolution Updates

  • Program records retain SPA feedback, saved PSA summaries, code, execution status, and parent identity; unavailable feedback is omitted.Successful evaluations are updated under database retention rules, while construction and evaluation failures retain separate status records and concurrent worker updates follow completion order.Source: §F.2 · p. 38
  • Successful seed evaluations initialize the database under the same retention rules, can update PSA, and do not save SPA reports or PSA snapshots in their database records.Failed seed evaluations retain their execution status.Source: §F.2 · p. 38

F.3 Additional SPA Statistics and Diagnostic Rules

  • SPA diagnostics compare four consecutive temporal windows and group intersections by location, using queue, phase-score, demand–priority, and post-change observations to guide inspection rather than estimate causal effects.Reports provide up to four revision suggestions, including prompts to examine green-hold or switching-margin rules when fW(pn) > 1.5CW.Source: §F.3 · p. 38

F.4 PSA Storage and Retrieval

  • PSA appends strategy records and retains the latest 50; its saved summaries combine up to eight high-scoring nondominated records and five recent dominated records.Records link to program identities, scores are rounded to four decimal places, and summaries are cached for identical code; a candidate’s saved summary is used for later parent revisions.Source: §F.4 · pp. 38–39
Loading 2610.09563v1…