PaperlayerView exact revision on arXiv

Source-linked AI summary

Semantics-Guided Automatic Tensorization for Multiobjective Evolutionary Algorithms: A Multi-Agent Framework

Zhenyu Liang, Beichen Huang, Bowen Zheng, Ran Cheng

arXiv:2609.02387v1cs.NE

TL;DR

MOEA implementations expose GPU-suitable parallelism but often encode it in CPU-oriented structures, creating an automation gap for tensorization without changing the optimization mechanism. EvoCoCo addresses this gap by reconstructing source semantics into a shared blueprint, exploring alternative tensor realizations, and using execution-guided validation, repair, and selection. Across 48 MOEAs, the framework improves migration reliability over one-shot translation, while fidelity and scaling results support its constrained restructuring formulation.

  • Problem

    MOEAs expose population-level parallelism, but mature CPU-oriented implementations require automated restructuring to express that computation as tensor operations while preserving the optimization mechanism.

  • Method

    EvoCoCo reconstructs algorithmic semantics, organizes them in a shared tensorization blueprint, explores alternative realizations, and applies execution-guided repair and selection.

  • Results

    EvoCoCo with Gemini 3 Flash reaches 93.33% execution pass and 78.75% convergence pass rates, exceeding the strongest one-shot condition by 20.41 and 17.08 percentage points, respectively.

  • Takeaways & Limitations

    The results support automatic MOEA tensorization as structured program restructuring constrained by reconstructed algorithmic states, operators, dependencies, and update relations.

  • Takeaways & Limitations

    The evidence covers heterogeneous PlatEMO-to-EvoX transformation and limited external implementations, not framework-independent generality, formal equivalence, or exact stochastic trajectory equivalence.

Abstract

from arXiv · show

Multiobjective evolutionary algorithms (MOEAs) naturally expose population-level parallelism, but many mature implementations encode their computation in sequential program structures designed for central processing units. Exploiting modern tensor computing platforms therefore requires more than direct code translation: the implementation must be restructured without changing the defining optimization mechanism of the underlying MOEA. We formulate automatic tensorization for MOEAs as semantics-guided computational restructuring and develop Evolutionary Code Conversion (EvoCoCo), a multi-agent framework that realizes this formulation. EvoCoCo reconstructs algorithm-specific states, dependencies, operators, and update logic into a structured semantic representation and organizes them through a shared tensorization blueprint. Specialized transformation branches then explore alternative tensor realizations, while execution feedback guides validation, repair, and candidate selection. Experiments on a benchmark of 48 MOEAs evaluate migration reliability, optimization fidelity, and computational scalability. Under matched large language model backends, EvoCoCo attains higher migration reliability than direct one-shot translation. Across the benchmark suites, 88.2% of valid comparisons satisfy the predefined optimization-fidelity criterion. The tensorized implementations also exhibit increasing acceleration on graphics processing units as population size or decision dimension grows, with median measured speedups ranging from $22.6\times$ under population scaling to $80.2\times$ under decision-dimension scaling. External-source and ablation studies further assess transfer beyond the main benchmark and the roles of the major framework components.

I. INTRODUCTION

MOEAs expose population-level parallelism, but mature CPU-oriented implementations often obscure it behind sequential structures. EvoCoCo addresses this automation gap through semantics-guided restructuring, shared representations, diversified tensorization, and execution feedback.

  • Motivation: MOEA computational costs can limit the practical scale of applications, despite substantial population-level parallelism.Objective evaluation, variation, ranking, selection, and archive operations can often be processed concurrently.
  • Automation gap: GPU tensorization requires reorganizing data representation, control structure, and state updates rather than translating source code line by line.CPU-oriented implementations combine loops, dynamic containers, conditional branches, and framework-specific state management.
  • Automation gap: Automatic tensorization requires coordinated functions for semantic reconstruction, target planning, alternative restructuring, runtime diagnosis, and candidate assessment.The paper motivates specialized reasoning roles that exchange structured intermediate representations under shared semantic constraints.
  • Framework: EvoCoCo formulates automatic tensorization as semantics-guided computational restructuring while preserving the underlying optimization mechanism.The software implementation is transformed, while the algorithmic semantics constrain admissible changes.
  • Framework: The framework combines specialized agents, a shared tensorization blueprint, alternative restructuring strategies, and closed-loop execution feedback.These components coordinate semantic analysis, rule retrieval, planning, diversified transformation, repair, and selection.
  • Evaluation: The evaluation uses a benchmark of 48 MOEAs and examines migration reliability, optimization fidelity, scalability, transfer, and component contributions.The study builds on heterogeneous MOEA structures and tensorization techniques including broadcasting, masking, batched scalarization, and tensor indexing.

III. SEMANTICS-GUIDED AUTOMATIC TENSORIZATION

The paper defines automatic tensorization as constrained restructuring of concrete MOEA implementations: source semantics are preserved while target representations and execution structures may change. A shared blueprint coordinates alternative realizations, which are validated and refined using execution evidence.

  • Problem formulation: Automatic tensorization transforms a concrete source implementation into a target tensor implementation while preserving principal operators, persistent states, dependencies, and update logic.The target may differ in data representation, control flow, framework interface, and execution model.
  • Problem formulation: Algorithmic semantics mean the principal operators, persistent states, dependencies, and update relations characterizing the source optimization mechanism.This definition does not require formal program equivalence or identical stochastic trajectories.
  • Problem formulation: Feasible target implementations must satisfy program, framework, runtime, numerical, and algorithmic-retention constraints.The constraints define the admissible target program space.
  • Problem formulation: Tensorization is a constrained restructuring objective that replaces avoidable individual-level or host-side population computation with batched tensor operations.The target remains compatible with its execution model while preserving reconstructed semantics.
  • Methodological overview: The methodological pipeline reconstructs semantics, builds a blueprint, generates alternative candidates, validates and refines them, and selects a validated implementation.Structured representations distinguish what the source does from how the target realizes it.
  • Methodological overview: EvoCoCo maps these functions to specialized roles coordinated through shared intermediate representations and execution-guided refinement.Role specialization separates semantic interpretation, target generation, planning, and execution diagnosis.

D. Semantic Reconstruction and Tensorization Blueprint

Semantic reconstruction extracts the source MOEA’s algorithmic states, workflow, dependencies, and computational structures before target generation. A tensorization blueprint then specifies shared target-side state mappings, tensor requirements, lifecycle rules, and framework constraints.

  • Semantic reconstruction: The Source Analysis Agent reconstructs a structured representation of the source implementation without generating target code.It records algorithm category, mechanisms, workflow, dependencies, helper functions, state updates, and termination.
  • Semantic reconstruction: The representation distinguishes persistent states from temporary values and records each state’s role, dimensions, lifetime, and dependencies.Examples include populations, objective values, ideal points, reference vectors, neighborhoods, archives, and velocities.
  • Blueprint construction: EvoCoCo constructs the blueprint B after source analysis and rule retrieval, before parallel candidate transformation.Algorithm 1 places semantic reconstruction and blueprint construction ahead of diversified restructuring and validation.
  • Semantic reconstruction: Source analysis records population size N, objective count M, decision dimension D, iteration budget G, and structures that constrain tensorization.It separates reformulable population computations from genuine sequential dependencies.
  • Blueprint construction: Context-aware rule retrieval selects target-framework requirements and validated tensorization practices relevant to the reconstructed mechanisms and risks.The retrieved subset is filtered by applicability and ranked by relevance.
  • Blueprint construction: The blueprint specifies target state architecture, execution workflow, tensor formulations, helper-function contracts, shapes, data types, initialization, and update rules.It maps source population-object operations to synchronized target state updates.
  • Blueprint construction: Candidate branches share constraints requiring interface compliance, consistent devices and data types, synchronous related-state updates, and minimal host-side computation.Individual-level loops and NumPy fallbacks are disallowed unless unavoidable sequential dependence is identified.

E. Diversified Computational Restructuring

EvoCoCo treats tensorization as a constrained search over alternative realizations that share the same semantics and blueprint. Candidates are independently validated, repaired using diagnostic feedback, and hierarchically selected using optimization, execution, and tensorization evidence.

  • Diversified restructuring: Multiple Tensorization Agents generate candidate implementations in parallel under shared source semantics, state architecture, framework constraints, and lifecycle requirements.Their differences represent restructuring hypotheses rather than independent interpretations of the source algorithm.
  • Transformation strategies: EvoCoCo instantiates six transformation biases: Broadcasting, Einsum Optimization, Masked Operations, In-Place Efficiency, Advanced Operations, and Tensorized Iterative Selection.These strategies target relations, contractions, branches, storage, indexing, and genuine sequential dependencies.
  • Transformation strategies: Each strategy produces a self-contained EvoX implementation while remaining constrained by the common blueprint and source-level requirements.Branches may change data layout, indexing, or control structure but must realize the same source mechanism.
  • Validation and repair: Validation combines static checks with runtime execution to detect interface, tensor, device, numerical, control-flow, and state-transition failures.A lightweight validation problem supplies common optimization and execution signals.
  • Validation and repair: Failed candidates are repaired using diagnostics, the source implementation, and retrieved rules without relaxing source or framework constraints.Candidates re-enter validation until passing or reaching the refinement budget, after which they are marked invalid.
  • Candidate selection: Candidate selection first groups validated implementations by comparable observed optimization outcomes, then considers execution time and tensorization assessment.The current realization uses hierarchical evidence rather than a fixed weighted score, with optimization considered after executability.
  • Evaluation: The benchmark evaluates migration reliability, optimization fidelity, and scalability across 48 heterogeneous MOEAs and multiple problem suites.Five independent migration attempts are made per source, and the resulting implementations are fixed for later fidelity and scaling experiments.

B. Migration Reliability

The paper defines migration reliability and optimization fidelity through staged validation and predefined comparison criteria, while measuring scalability through normalized runtime speedup as problem scale changes.

  • Migration Reliability: Migration reliability requires generated implementations to pass syntax, execution, and convergence stages, with convergence requiring the predefined optimization criterion.Failures are assigned to the earliest observed stage; numerical failures and timeouts are execution subtypes, while tensorization violations are tracked separately.
  • Migration Reliability: Migration success rate counts attempts reaching convergence relative to all attempts.The convergence-pass level is the required threshold for a successful migration attempt.
  • Optimization Fidelity: Optimization fidelity compares selected tensorized implementations with PlatEMO references using repeated runs under matched dimensions, population sizes, and evaluation budgets.Exact agreement is not required because implementations may differ in random-number generators, numerical libraries, and execution orders.
  • Optimization Fidelity: The fidelity criterion counts both improved and sufficiently preserved outcomes as passes, using εabs = 0.10 and εrel = 2.0 to accommodate IGD scale differences.Improved means IE ≤ IP; preserved outcomes satisfy either absolute or relative tolerance, while other increases are labeled IGD Degradation.
  • Optimization Fidelity: A MOEA passes the algorithm-level fidelity criterion when ρa ≥80%, while framework-level success additionally requires ρoverall ≥80% and at least 80% of MOEAs to pass individually.Reference-invalid MOEA–problem comparisons are excluded from coverage denominators rather than treated as failures of tensorized implementations.
  • Computational Scalability: Computational scalability measures runtime advantage as problem scale changes, using average execution time per generation and varying population size or decision dimension separately.Timing excludes initialization and warm-up, synchronizes GPU operations, and reports timeouts, out-of-memory events, and execution failures separately.

V. EXPERIMENTAL STUDY

The experimental study evaluates EvoCoCo across 48 MOEAs for migration reliability and optimization fidelity. Matched-backend comparisons favor EvoCoCo over one-shot translation, while most valid benchmark comparisons meet the predefined fidelity criterion.

  • Experimental design: The study evaluates five progressive research questions spanning reliable transformation, optimization fidelity, runtime scaling, external transfer, and component contributions.The benchmark includes 48 PlatEMO MOEA implementations and evaluates migration reliability, optimization fidelity, computational scalability, transfer, and ablations.
  • Migration reliability: Each migration condition contains 240 attempts, with EvoCoCo generating six candidates per attempt and applying validation, repair, and branch-level selection.One-shot translation directly generates one output, whereas EvoCoCo uses strategy-guided candidates and execution-guided refinement.
  • Migration reliability: 93.33% execution and 78.75% convergence pass rates make EvoCoCo with Gemini 3 Flash the strongest condition, covering all 48 benchmark MOEAs.The strongest one-shot condition, GLM-5.1, reaches 72.92% execution and 61.67% convergence, covering 45 MOEAs.
  • Migration reliability: 52.08, 38.34, and 42.91 percentage-point convergence gains over matched one-shot backends show higher migration reliability for the complete EvoCoCo workflow.EvoCoCo produces more converged attempts than matched one-shot methods on 38, 35, and 43 of 48 MOEAs, respectively.
  • Optimization fidelity: 88.2% of valid MOEA–problem comparisons satisfy the optimization-fidelity criterion, comprising 724 Improved and 956 Preserved cases among 1,904 valid comparisons.The 48 implementations are evaluated on 1,920 combinations spanning DTLZ1–DTLZ7, WFG1–WFG9, LSMOP1–LSMOP9, and MaF1–MaF15.
  • Optimization fidelity: Fidelity coverage exceeds 80% in all four benchmark families, and 41 of 48 tensorized implementations reach at least 80% algorithm-level coverage.Coverage is 96.5% for WFG, 87.3% for MaF, 84.8% for LSMOP, and 84.0% for DTLZ; the results support comparable outcomes under the stated criterion, not trajectory-level equivalence.

C. RQ3: Computational Scalability

RQ3 evaluates whether tensorized MOEAs gain runtime advantage as population size or decision dimension increases. Across 48 implementations, acceleration generally increases with scale, with larger aggregate gains under decision-dimension scaling, although results vary by algorithm and boundary cases constrain comparisons.

  • Aggregate scaling results: 22.6× median measured speedup under population scaling and 80.2× under decision-dimension scaling, with substantial heterogeneity across MOEAs and scale settings.The corresponding geometric means are 29.9× and 71.5×, respectively.
  • Scale-wise distributions: Median speedup under population scaling rises from 4.5× at N = 256 to 77.5× at N = 16384.The widening interquartile ranges show that benefits vary across implementations and scales.
  • Scale-wise distributions: Median speedup under decision-dimension scaling rises from 62.1× at D = 1024 to 194.8× at D = 65536.The benefit varies with the computational structure of the underlying MOEA implementation.
  • Representative trajectories: 37339.0× is the largest reported representative speedup under population scaling, achieved by MOEA/D-DE at N = 16384.WASF-GA reaches 5865.7× at the same population size; these are extreme cases rather than typical acceleration.
  • Representative trajectories: 7771.6× and 1935.9× are achieved by PESA-II and LSMOF, respectively, at D = 65536.DM-MOEA reaches the largest measured speedup under decision-dimension scaling: 23467.4× at D = 8192.

E. RQ5: Component Contributions

The ablation results distinguish the roles of EvoCoCo’s components: repair and multi-branch generation most directly support migration reliability, while blueprint construction and rule retrieval support code construction and adaptation. The broader discussion bounds the evidence to evaluated environments and empirical fidelity criteria.

  • Ablation results: 98.3% execution pass and 83.3% convergence rates for Full EvoCoCo fall to 60.0% and 41.7% without the Repair Agent.All variants retain a 100.0% syntax pass rate; failures after repair removal mainly involve EvoX API misuse, unavailable APIs, and tensor-shape mismatches.
  • Ablation results: Using one branch reduces execution pass rate to 68.3% and convergence rate to 40.0%, showing that alternative tensorization strategies contribute to migration reliability.Removing rule retrieval or the Blueprint Agent produces smaller reductions and more dependency, interface, and initialization-related errors.
  • Ablation results: Conditional IGD is computed only over converged attempts, so its interpretation requires convergence rate; w/o Blueprint Agent has mean IGD 0.0814 but 78.3% convergence versus 83.3% for Full EvoCoCo.The study assigns blueprint construction and rule retrieval to code construction, repair to execution reliability, and multi-branch generation to obtaining converged implementations.
  • Interpretation: Most migration failures occur after syntactically valid code, when framework requirements, tensor-state consistency, and optimization requirements must be satisfied simultaneously.Execution-guided refinement and diversified restructuring improve reliability, while blueprint construction and rule retrieval constrain reconstruction and realization.
  • Framework interpretation: EvoCoCo’s restructuring is evolutionary in structure: alternative realizations share a semantic blueprint, receive execution feedback, are refined, and are selected using target-side evidence.The framework is not formulated as a conventional evolutionary algorithm.
  • Scope and limitations: The evidence supports feasibility for heterogeneous PlatEMO-to-EvoX transformation but not framework-independent generality, formal equivalence, or resource-normalized superiority over direct translation.Future work targets additional environments, stronger optimization-aware validation, and memory-efficient restructuring.

I. OVERVIEW

The supplementary evaluation studies EvoCoCo across migration reliability, optimization fidelity, computational scalability, external transfer, and component contributions. It uses 48 heterogeneous PlatEMO algorithms, repeated conversion attempts, DTLZ2 validation, and multiple model/backend conditions.

  • Evaluation scope: The supplementary document addresses five research questions covering migration reliability, optimization fidelity, computational scalability, external transfer, and component contributions.Its sections report migration outcomes, fidelity across benchmark suites, scaling results, external and legacy implementations, and ablations.
  • Experimental setting: The study uses two hardware environments, with migration, external-transfer, and ablation experiments run locally and fidelity and scalability experiments run on a server.The local workstation includes an NVIDIA GeForce RTX 5060 Ti with 16 GB of GPU memory and an Intel Core Ultra 7 265K CPU.
  • Experimental design: Each of seven migration conditions contains five independent attempts for each of 48 source MOEA implementations, yielding 240 attempt-level implementations per condition.The final EvoX implementation returned by one conversion attempt is the experimental unit.
  • Experimental design: One-shot generation returns one candidate, whereas EvoCoCo performs analysis, rule retrieval, blueprint construction, six strategy-guided branches, validation, repair, and final selection.The six branch candidates are reduced to one attempt-level output through hierarchical selection.
  • Experimental design: Candidates are validated on DTLZ2 with N = 100, M = 3, D = 12, 100 generations, and a 60-s time limit.Convergence requires execution without persistent NaNs and final IGD below 0.25.
  • Benchmark composition: The 48 benchmark algorithms are grouped into dominance-based, decomposition-based, indicator-based, and specialized-operator-based classes according to their primary environmental-selection or population-update mechanisms.Hybrid algorithms are assigned by the mechanism most directly determining survival or population updating.

C. Failure-Stage Decomposition

Failure-stage analysis separates syntax, execution, convergence, and successful migration outcomes across 240 attempts per condition. The results show that EvoCoCo shifts failures away from execution and produces broader convergence than matched one-shot translation, with backend- and algorithm-dependent variation.

  • Outcome definitions: The four outcome categories are mutually exclusive and sum to 240 per condition; execution failure means non-completing valid code, while convergence failure means executable code missing the final-IGD criterion.This classification assigns each attempt to the earliest unsuccessful evaluation stage.
  • Failure-stage comparison: Execution-stage failures comprise 62.92%–73.75% of matched one-shot conditions but only 6.67%–17.50% under EvoCoCo.More EvoCoCo candidates therefore reach optimization evaluation; larger convergence-failure segments must be read alongside expanded converged segments.
  • Algorithm-level stability: EvoCoCo with Gemini 3 Flash is the only condition with no algorithm at 0/5 convergence and achieves 5/5 convergence on 19 algorithms.Table S.V summarizes convergence counts across five attempts per algorithm.
  • Paired comparisons: EvoCoCo with Gemini 3 Flash beats Gemini 3 Flash one-shot on 38/48 algorithms, ties 3, loses 7, and adds 125 converged attempts.The Holm-adjusted sign-test p-value is 1.87 × 10^-5.
  • Paired comparisons: EvoCoCo with DeepSeek V4 Pro beats its one-shot counterpart on 35/48 algorithms, ties 9, loses 4, and adds 92 converged attempts.The Holm-adjusted sign-test p-value is 2.35 × 10^-6.
  • Interpretive caveat: The algorithm-level directional tests do not establish a causal pipeline effect because model versions, reasoning behavior, concurrency, and worker settings were not fully controlled across batches.They quantify directional consistency at the algorithm level.

E. Conditional Quality, Runtime, and Token Use

Quality and runtime statistics are computed over converged runs, while token use measures LLM generation resources separately from benchmark execution. The results indicate backend-dependent convergence patterns and a resource–reliability trade-off, rather than a single universal best configuration.

  • Interpretation basis: IGD and runtime statistics describe only the successful converged subset, not end-to-end migration reliability.This conditioning separates optimization quality and execution time from the probability of obtaining a usable migration.
  • Token use: EvoCoCo uses more LLM tokens than one-shot generation while attaining higher reliability and coverage.With Gemini 3 Flash, EvoCoCo uses about ten times more tokens per converged result, expands convergence from 64 to 189 runs, and coverage from 25 to 48 algorithms.
  • Token use: Token efficiency therefore represents a resource–reliability trade-off rather than a standalone migration-quality ranking.Provider prices, cache accounting, and source completeness differ across batches, so monetary cost is not compared.
  • Backend comparison: The backend effect is algorithm dependent: several algorithms remain difficult across backends, while CMOEA-MS, EFR-RR, MOEA-D-DU, and PICEA-g converge in all 15 attempts.Gemini 3 Flash avoids every 0/5 result, whereas other backends have algorithm-specific zero-convergence cases.
  • Algorithm-level results: Table S.IX reports algorithm-level execution/convergence matrices as E/C counts among five attempts for each algorithm and condition.The matrix provides the complete per-algorithm migration breakdown.

G. Failure Analysis

The fidelity analysis compares tensorized EvoX implementations with matched PlatEMO references across 48 MOEAs and four benchmark suites. Most valid comparisons satisfy the predefined Improved-or-Preserved criterion, while invalid references are excluded from coverage denominators.

  • Evaluation rule: Reference-invalid cases are excluded when PlatEMO lacks the required number of usable reference runs.The criterion labels these combinations Reference invalid rather than IGD degradation.
  • Optimization-fidelity coverage: 88.2% of valid comparisons satisfy the optimization-fidelity criterion, comprising 724 Improved and 956 Preserved outcomes among 1,904 valid comparisons.The 1,920 combinations include 16 invalid PlatEMO references and 224 IGD-degradation outcomes.
  • Optimization-fidelity coverage: 85.4% of benchmark MOEAs achieve at least 80% algorithm-level fidelity coverage, corresponding to 41 of 48 tensorized implementations.Coverage is computed over valid reference problems.
  • Reference validity: Nine of the 16 invalid references result from PlatEMO timeouts, while seven result from PlatEMO execution errors.These cases are reported for completeness but excluded from effective coverage denominators.
  • Threshold sensitivity: The selected absolute and relative IGD tolerances are 0.10 and 200%, respectively, and lie within a stable neighborhood of similar coverage values.Coverage changes gradually as either tolerance varies rather than jumping at the selected setting.

E. Representative Convergence Trajectories

The scaling evaluation reports complete population-size and decision-dimension results for 48 tensorized implementations, alongside representative fidelity-preserving convergence trajectories. Measured GPU acceleration is substantial across completed comparisons but is accompanied by timeout, execution-error, and out-of-memory exceptions.

  • Representative convergence trajectories: Figure S.5 shows 16 representative trajectories from Improved or Preserved combinations, with four algorithms contributing one trajectory from each benchmark suite.Each displayed algorithm has at least 95% overall effective coverage.
  • Scaling setup: Population scaling varies N from 256 to 16384 at D = 12, while dimension scaling varies D from 1024 to 65536 at N = 1000.EvoX is the tensorized GPU implementation and PlatEMO is the MATLAB CPU baseline.
  • Runtime scalability: Median measured speedups are 22.6× under population scaling and 80.2× under decision-dimension scaling.The corresponding geometric means are 29.9× and 71.5×.
  • Scaling exceptions: PlatEMO reaches the time limit in 30 population-scaling and 42 dimension-scaling cases, with valid EvoX runtimes contributing lower-bound speedups in 26 and 34 cases.The remaining timeout cases coincide with EvoX out-of-memory events.
  • Scaling exceptions: EvoX encounters 6 population-scaling and 11 dimension-scaling out-of-memory events, while PlatEMO records 15 and 17 execution errors, respectively.Exception counts are summarized separately by scaling axis and failure type.

V. TRANSFER TO EXTERNAL MOEA IMPLEMENTATIONS

The external-transfer experiment tests EvoCoCo on ten standalone or legacy MATLAB/Octave implementations using matched five-attempt comparisons with one-shot generation. EvoCoCo improves execution and convergence reliability across diverse external sources, although success is not universal.

  • Conversion workflow: The workflow combines analysis, rule retrieval, blueprint construction, six tensorization branches, repair, and selection using execution feedback.The six strategies are Broadcasting, Einsum Optimization, Masked Operations, In-Place Efficiency, Advanced Operations, and Tensorized Iterative Selection.
  • Generation diagnostics: The 50 EvoCoCo runs produce 300 branch records, with 248 successful and 52 failed branches; 111 branches receive one or two runtime repairs.Recorded repairs comprise 39 branches with one repair and 72 with two repairs.
  • Validation protocol: Matched generated implementations undergo a lightweight 50-generation DTLZ2 validation run before final independent evaluation for 100 generations.The validation run supports execution validation and repair and is excluded from the final evaluation.
  • Aggregate transfer reliability: EvoCoCo achieves 100% syntax, 96% execution, and 62% convergence pass rates, compared with 70%, 34%, and 18% for one-shot generation.Each method contributes 50 matched attempts across the ten sources.
  • Algorithm-level outcomes: EvoCoCo obtains at least one converged implementation for nine of ten sources, while one-shot generation converges only for DEMO and ISDE+.DEMO and Two-Arch2 each achieve five of five converged EvoCoCo attempts.

E. Truncation and Residual Failures

Failure analysis links EvoCoCo’s reliability to distinct transformation components and identifies truncation as a dominant one-shot failure pattern. Ablations show that repair and multi-branch generation are especially important, while residual EvoCoCo failures remain concentrated in convergence.

  • Truncation and residual failures: Output truncation dominates one-shot syntax failures, especially for longer or structurally complex sources.Many failing files terminate inside tokens, expressions, imports, function calls, or formatted strings.
  • Residual failures: EvoCoCo’s two runtime failures occur for ISDE+ and R-DEMO, while its other unsuccessful attempts are executable but fail the convergence criterion.The authors therefore characterize transfer as improving the probability of usable transformation rather than guaranteeing convergence.
  • Ablation results: Full EvoCoCo achieves the highest execution and convergence rates, while removing repair or multi-branch generation and selection causes the largest aggregate degradation.Removing the Blueprint Agent or rule retrieval retains higher aggregate success but changes static and interface failure profiles.
  • Failure subtypes: The Repair Agent ablation produces 11 API-misuse or missing-API cases and seven tensor-shape mismatches despite retaining high static validity.These defects emerge primarily during execution.
  • Failure subtypes: The rule-retrieval ablation records 18 static issues but only three API or shape cases, indicating a different failure profile from repair removal.Retrieved implementation rules mainly prevent invalid dependencies and undefined elements in this analysis.
  • Algorithm-level effects: Without repair, all five MOEA-D-AWA and all five SIBEA attempts fail during execution, whereas the complete pipeline executes all ten attempts.Without multi-branch generation and selection, only one of five attempts converges for DM-MOEA, SIBEA, and WOF.
Loading 2609.02387v1…