LLM-Guided Program Evolution for Circle Packing: Breaking 10 Packomania Records for $28
Abstract: We present Discovery Loop, a lightweight system that uses a LLM to iteratively evolve optimization algorithms. Starting from a simple seed solver, the LLM proposes algorithmic improvements guided by a scoreboard of results and a history of prior ideas. Each candidate is evaluated against an independent verifier; improvements are kept and failures discarded. Applied to the Packomania circle-packing benchmark (csqv: maximize the sum of radii of N variable-radius circles in the unit square), the system improved the best known solutions for 10 values of N in the range 101-114, with gains of 2.4%-5.4% over prior records, all within 15 iterations and at a total LLM cost of $27.72. These results have been independently accepted by Packomania. We describe the method, analyze cost-efficiency dynamics including an adaptive plateau-detection mechanism, and discuss implications for democratizing automated scientific discovery.
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
Explain it Like I'm 14
1. What is the paper about?
This paper describes a computer system called Discovery Loop. It uses a LLM, or LLM—the kind of AI that can understand and write computer code—to improve programs that solve difficult problems.
The researchers tested Discovery Loop on a circle-packing problem:
Put many circles inside a square so that they do not overlap, while making the total size of the circles as large as possible.
The system created and tested improved programs again and again. According to the paper, it found better solutions than the previous records for 10 different circle-packing challenges, spending only $27.72 on the AI model.
The main idea is that advanced algorithm research might not always require a large company or expensive computer cluster. A single person with a powerful AI tool and an ordinary computer might also make useful discoveries.
2. What questions did the researchers ask?
The paper focused on several main questions:
- Can an LLM improve a computer program for solving a difficult mathematical problem?
- Can this be done with only one computer instead of a large research facility?
- Can the system find genuinely new strategies, rather than simply changing numbers in an existing program?
- How much does this process cost?
- When should the system stop trying because further attempts are unlikely to help?
In simpler terms, the researchers wanted to know:
Can an AI act like a creative computer scientist, suggesting new ways to solve a problem, and can it do this cheaply?
3. What problem did they study?
Imagine a square box with sides of length 1. The researchers want to place $N$ circles inside it.
The circles may have different sizes, but they must follow two rules:
- Every circle must stay completely inside the square.
- No two circles may overlap.
The goal is to make the sum of all the circle radii as large as possible. A circle’s radius is the distance from its center to its edge. So, the larger the total radius, the more “circle material” has been fitted into the square.
This is difficult because moving one circle can affect many others. There are also many possible arrangements, and most arrangements are not the best ones.
4. How did Discovery Loop work?
Discovery Loop started with a basic circle-packing program called the seed solver. The system then repeated the following process:
- The LLM was shown the current best program.
- It was shown a scoreboard describing how well the program performed.
- It was shown a history of ideas that had already been tried.
- The LLM suggested a completely new version of the program.
- The new program was tested on several circle-packing tasks.
- An independent checker made sure the answer was legal.
- If the new program performed better, it became the new “champion.” Otherwise, it was discarded.
This is similar to training for a sports competition. A team keeps its best player, tries a new player, and replaces the old one only if the new player performs better.
What does “program evolution” mean?
In this paper, program evolution means repeatedly creating new versions of a program and keeping the versions that work best.
The LLM was not just asked to adjust settings. It could redesign major parts of the solver. For example, it could decide to:
- Start with circles arranged in a honeycomb-like pattern.
- Search around a promising arrangement instead of starting randomly each time.
- Move circles in groups.
- Remove poorly placed circles and try putting them back in new spaces.
- Use several searches running at the same time.
What were some technical methods?
The original paper uses several technical terms:
- Penalty method: The program temporarily gives a bad score to arrangements where circles overlap. This encourages the computer to move toward legal arrangements.
- Local search: The program makes small changes to an arrangement to see whether it improves.
- Basin hopping: The program makes a larger jump to escape a poor arrangement, then searches locally again. This is like climbing a hill, jumping to another hill, and climbing again.
- Linear programming: A mathematical method for finding the best values under a set of rules. In this case, it helped choose circle sizes.
- L-BFGS-B and SLSQP: Names of mathematical optimization tools used to improve the positions and sizes of the circles.
- Hexagonal lattice: A honeycomb-like arrangement. Circles placed this way can often fit together efficiently.
- Parallel search: Several searches run at once on different computer processor cores, like several people looking for the best answer independently.
The LLM produced a complete replacement program each time rather than changing only a few lines. This made each new attempt independent and easier to test.
5. How did the researchers check the results?
The researchers used a separate verifier, which is a checking program that did not share code with the solver.
The verifier checked that:
- Every circle stayed inside the square.
- No circles overlapped.
- The total radius was calculated correctly.
- Tiny numerical errors did not make an illegal arrangement appear legal.
This independent checking was important. Without it, a program might accidentally—or deliberately—report an answer that looked good but did not really follow the rules.
6. What did the researchers find?
The system was tested on 12 different target problems involving between 26 and 114 circles.
It:
- Beat the previous records for 10 of the 12 main targets.
- Improved the previous records by about 2.4% to 5.4%.
- Matched or nearly matched the old records for the other two targets.
- Used an LLM budget of $27.72.
- Ran for about eight hours on a consumer desktop computer.
- Used a maximum of 15 LLM iterations before reaching the budget limit.
The results were reportedly checked independently and accepted by the Packomania circle-packing database.
Some of the strongest improvements came from ideas such as:
- Using hexagonal starting patterns.
- Running multiple searches at the same time.
- Carefully polishing the places where circles touch.
- Removing weakly placed circles and reinserting them into better positions.
These ideas were more than simple changes to numbers. They changed how the search worked.
7. What did the cost analysis show?
The system made its biggest progress early.
During the first few attempts, it spent about $4.96 and improved the results noticeably. Later, it spent much more money but made only tiny additional improvements.
This is called diminishing returns. It is like studying for a test: the first hour may greatly improve your score, but the tenth extra hour may help only a little.
The researchers created a feature called plateau detection. A plateau is a period when results stop improving much. The system watches for this and stops early when continued searching is unlikely to be worthwhile.
Based on testing, the researchers believe this would have reduced the cost by about half, from $27.72 to roughly$13.95, while losing only a very small amount of solution quality.
8. Why are these results important?
The results matter for two main reasons.
First, the system found better solutions to a long-standing mathematical challenge. This shows that an LLM can sometimes suggest useful algorithmic ideas, not just write ordinary code.
Second, the experiment suggests that automated algorithm discovery may be available to individuals and small research groups. Earlier systems such as AlphaEvolve and FunSearch were designed for organizations with large computing resources. Discovery Loop used:
- One LLM call per attempt.
- One ordinary computer.
- Local parallel processing.
- Open-source code.
- Less than $30 in LLM costs.
This does not mean every difficult problem can be solved so cheaply. However, it shows that the basic idea can work on at least one problem where testing solutions is relatively fast.
9. What are the limitations?
The paper also points out several weaknesses.
The system was tested mainly on one type of problem: circle packing. It is not clear whether it would work as well for other problems, especially those that require much more computing time.
The system also kept only one main champion program at a time. A larger system could keep many different programs and explore more ideas.
Its success depended on the LLM producing correct, working Python programs. The paper says that tests on a different problem involving mixed-integer programming had many code-generation failures.
Finally, improvement slowed down quickly when the system continued working on the same fixed set of targets. The system may be more useful if it moves on to new problems instead of endlessly improving one small group of examples.
10. What could this mean for the future?
The research suggests that LLMs could become assistants for discovering new algorithms in areas such as:
- Delivery and transportation planning.
- School or employee scheduling.
- Factory and supply-chain management.
- Engineering design.
- Mathematics and computer science education.
A student could think of Discovery Loop as a tireless teammate. The student explains the problem, the AI suggests new strategies, the computer tests them, and a trusted checker decides whether they are correct.
However, human supervision would still be important. An AI may produce code that does not work, misunderstand the goal, or find an answer that seems good but fails under careful checking. Independent verification remains essential.
Conclusion
The paper presents a small, inexpensive system that uses an LLM to repeatedly invent and test new optimization programs. On the circle-packing problem, it reportedly broke 10 existing records for less than $30.
The biggest lesson is not only that the circles were packed more efficiently. It is that AI-assisted algorithm discovery may be becoming accessible beyond large technology companies and research laboratories. With a good problem, careful testing, and independent verification, an individual researcher may be able to use an ordinary computer and an LLM to explore new ideas in mathematics and engineering.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
- The contribution of LLM-guided evolution is not isolated. All 10 record improvements are reported as occurring at iteration 0 with the seed solver, so the paper does not establish how much additional performance came from the LLM-generated candidates rather than from the initial solver.
- There is no ablation study of system components. The effects of the LLM, scoreboard, idea history, full-program replacement, per-target best tracking, independent verification, and plateau detection are not measured separately.
- The seed solver is insufficiently specified for reproduction. Important details such as initialization distributions, penalty coefficients, stopping criteria, LP formulation, numerical tolerances, random seeds, and the number of restarts are omitted.
- The experimental results are based on a single run. No repeated runs, confidence intervals, variance estimates, or sensitivity analyses are provided for the stochastic solver, LLM outputs, or evaluation process.
- The selected target set is not justified. The study evaluates 12 manually selected values of , omitting nearby instances such as , , , and ; this leaves open whether the method generalizes across the full Packomania range.
- The reported records are not compared with a consistent set of contemporary baselines. The paper does not benchmark the seed solver, standard state-of-the-art packing algorithms, or non-LLM program-search methods under matched computational budgets.
- The quality of the LLM-generated improvements is not independently attributed. The claim that the discovered methods are “genuine algorithmic innovations” is not supported by controlled experiments showing that each named innovation improves performance relative to an otherwise identical solver.
- The evaluation budget is not normalized across candidates. Candidate solvers may use different amounts of CPU time, random restarts, memory, and internal computation, making score comparisons difficult to interpret as algorithmic improvements.
- The scoring and selection rule may obscure per-instance performance. The aggregate score can favor improvements on some targets while sacrificing others, but the paper does not analyze trade-offs, fairness across targets, or whether candidates were rejected despite producing meaningful specialized improvements.
- The per-target best results are not necessarily produced by one deployable solver. Because best results are retained across different candidate solvers, the reported collection of records may require multiple specialized solvers rather than a single algorithm that achieves all listed values.
- The independent verifier is not described in sufficient technical detail. The paper does not specify its floating-point arithmetic, feasibility-shrink magnitude, treatment of near-contact configurations, reproducibility across platforms, or how “zero tolerance” is implemented numerically.
- The relationship between verifier shrinkage and the reported objective is unclear. It is not reported whether the tabled sums are pre-shrink or post-shrink values, nor how much objective value is lost during strict feasibility correction.
- The Packomania acceptance process is not independently documented. Submission identifiers, archived records, verifier outputs, and exact solution files are not included in the paper, limiting external confirmation of the claimed improvements.
- The plateau detector is validated only retrospectively on one trajectory. Its reported savings depend on a single run and cannot establish that the chosen window and threshold work reliably on other problems, models, target sets, or random seeds.
- The plateau criterion is not compared with alternative stopping policies. There is no analysis against fixed iteration limits, sequential statistical tests, marginal-cost rules, or model-based stopping methods.
- The reported counterfactual cost saving may be optimistic. Stopping at iteration 9 could alter later solver-selection dynamics, and the paper does not perform prospective runs to verify that the claimed quality-cost trade-off is reproducible.
- The cost accounting is underspecified. The paper does not state token counts, input/output pricing, retries, failed calls, cached context costs, or whether CLI and infrastructure costs were excluded.
- The runtime comparison is incomplete. Wall-clock time is reported, but total CPU time, parallelization overhead, solver time by target, and the computational cost of competing methods are not provided.
- Model dependence is acknowledged but not systematically evaluated. Results from Claude Fable 5.1 are not compared with other LLMs, model temperatures, prompting strategies, context lengths, or model versions.
- The claimed reproducibility is vulnerable to model and benchmark drift. The use of a live Packomania endpoint and a proprietary model may produce different records, prompts, or outputs over time; no frozen benchmark snapshot or model configuration is supplied.
- The MIPLIB failure-rate claim is not substantiated. The paper mentions a 75% code-generation failure rate but gives no instance list, sample size, failure taxonomy, prompts, baseline, or results, preventing meaningful interpretation.
- Generalization beyond circle packing remains untested. The paper provides no successful experiments on scheduling, routing, combinatorial optimization, continuous optimization, expensive simulations, or problems with non-geometric constraints.
- Scalability is unknown. The study does not evaluate larger , substantially more targets, higher-dimensional packing, alternative container geometries, or instances whose evaluations exceed the 120-second timeout.
- The search strategy may be vulnerable to premature convergence. Maintaining a single champion and replacing it with complete solver rewrites can discard complementary ideas, but the paper does not compare this design with populations, archives, branching search, or ensemble solvers.
- The history mechanism is not analyzed. It is unknown whether the last 12 ideas are sufficient, whether longer histories improve or degrade search, and how duplicate or contradictory proposals are handled.
- Candidate failures are not systematically characterized. The paper reports no breakdown of compilation errors, timeouts, infeasible outputs, verifier failures, numerical failures, or low-quality but valid candidates.
- The effect of randomness is not controlled. Random seeds for candidate solvers and evaluations are not reported, and it is unclear whether a candidate’s apparent improvement reflects algorithmic quality or favorable stochastic variation.
- The prior-record comparison may conflate benchmark improvements with methodological progress. Since the seed solver already exceeds many prior records substantially, the paper does not explain whether the Packomania records were outdated, generated under different conventions, or directly comparable.
- No optimality or near-optimality bounds are provided. The improvements establish new best-known solutions but do not indicate how close the solutions are to theoretical upper bounds or global optima.
- The geometric structure of the resulting packings is not analyzed. The paper does not report contact graphs, symmetry, lattice defects, radius distributions, or structural differences from prior records that could explain why the solver succeeds.
- The claimed democratization benefits are not empirically evaluated. Assertions about accessibility for individual researchers, education, and engineering applications are not supported by user studies, deployment experiments, or cost comparisons across domains.
- The paper does not assess security and reliability risks of executing LLM-generated code. Sandboxing, resource isolation, malicious or unintended code behavior, dependency control, and protection of the evaluation environment are not discussed.
- The long-term value of discovered code is unclear. It is not shown whether the evolved solvers remain effective when rerun independently, transferred to unseen instances, or maintained without continued LLM interaction.
Practical Applications
Immediate Applications
The paper’s main immediately deployable contribution is a lightweight workflow for using an LLM to propose complete optimization programs, evaluate them automatically, and retain only independently verified improvements.
- Local optimization-solver improvement for engineering teams
- Sector: Engineering, manufacturing, logistics, operations research.
- Organizations can adapt the open-source
Discovery Looparchitecture to improve existing solvers for scheduling, routing, facility layout, resource allocation, and packing. - A practical workflow would provide the LLM with:
- the current solver source code,
- objective and constraint definitions,
- benchmark results,
- previously attempted ideas, and
- an independent feasibility checker.
- Candidate programs could be evaluated in parallel on a workstation or small server, with only verified improvements promoted.
- Dependencies: The target problem must have a relatively cheap automated evaluator; generated code must run in a sandbox; and an independent verifier must be available. The paper’s poor results on mixed-integer programming indicate that performance may degrade for more complex problem representations.
- Automated improvement of geometric and layout optimization
- Sector: Robotics, warehouse design, computer-aided design, manufacturing, telecommunications.
- The discovered techniques—structured initialization, basin hopping, contact-graph polishing, defect removal and reinsertion, and parallel “island” searches—can be incorporated into tools for:
- warehouse and shelf layout,
- component placement,
- sensor positioning,
- geometric nesting,
- antenna or wireless-cell placement, and
- robot workspace allocation.
- The circle-packing implementation can serve as a starting problem plugin, with domain-specific objectives and constraints substituted for the packing equations.
- Dependencies: Real-world layouts often include obstacles, nonuniform shapes, discrete placement rules, and multiple objectives. These additions may require specialized representations and stronger validation than the demonstrated unit-square problem.
- Cost-controlled algorithm experimentation
- Sector: Software engineering and research computing.
- The plateau detector can be integrated into automated code-generation and optimization pipelines to stop LLM experimentation when recent iterations produce negligible gains.
- A practical implementation would monitor:
- whether recent candidates are accepted,
- improvement over a rolling window,
- evaluation cost per candidate, and
- the marginal value of further searches.
- This could reduce API expenditure and compute waste. In the reported backtest, stopping earlier would have reduced LLM cost by approximately 50% with only a very small loss in the aggregate benchmark score.
- Dependencies: The stopping threshold must be calibrated to the application. A small improvement may be commercially important in one setting and irrelevant in another.
- Benchmark-solving and reproducible mathematical experimentation
- Sector: Academia and computational mathematics.
- Individual researchers can use the open-source system to explore established optimization benchmarks without access to a large computing cluster.
- The workflow supports reproducible experimentation by preserving:
- the solver version,
- the generated idea description,
- benchmark scores,
- rejection or acceptance status,
- verification outputs, and
- submission records.
- This is particularly suitable for combinatorial geometry, metaheuristics, and numerical optimization courses or research projects.
- Dependencies: Results should not be treated as reliable solely because an LLM generated them. Independent verification, fixed evaluation protocols, random-seed documentation, and comparisons with accepted benchmark records remain necessary.
- Teaching tool for optimization and AI-assisted programming
- Sector: Education and academic training.
- Instructors can use the system to demonstrate:
- local search and basin hopping,
- initialization strategies,
- constraint verification,
- algorithmic ablation,
- cost–quality trade-offs,
- reproducibility, and
- the difference between parameter tuning and architectural algorithm changes.
- Students could compare LLM-generated proposals such as lattice initialization or defect migration against random-restart baselines.
- Dependencies: Educational deployments require code sandboxing, transparent grading criteria, and instruction on validating AI-generated code rather than accepting it uncritically.
- Independent verification services for AI-generated optimization code
- Sector: Software assurance, scientific computing, industrial AI.
- The paper’s verifier design can be used as a general pattern for evaluating generated solvers:
- keep solver and verifier implementations independent,
- recompute objectives from raw outputs,
- enforce strict feasibility checks, and
- reject numerical artifacts.
- This could become a reusable testing component in internal optimization platforms or continuous-integration pipelines.
- Dependencies: “Zero tolerance” is practical for the paper’s geometric constraints but may be inappropriate for noisy, stochastic, or floating-point-heavy applications. Domain-specific tolerances must be justified and tested.
- Personal and small-business planning tools
- Sector: Daily life, small business, scheduling.
- The same loop could improve programs for limited-scale tasks such as:
- assigning employees to shifts,
- arranging events within rooms,
- planning deliveries,
- allocating household or office storage, or
- balancing budgets under stated constraints.
- The result would not necessarily be a consumer-facing autonomous optimizer immediately, but rather a locally run assistant that proposes and tests alternative planning algorithms.
- Dependencies: Users must provide accurate constraints and objective priorities. Poorly specified objectives could produce solutions that are mathematically efficient but impractical or unfair.
Long-Term Applications
The longer-term opportunities require broader validation, larger evaluation infrastructures, domain-specific safety controls, or research into how well the approach transfers beyond circle packing.
- General-purpose optimization-agent platforms
- Sector: Software, enterprise operations, logistics, finance, energy.
- A future platform could accept a formal optimization problem and automatically:
- 1. generate a seed solver,
- 2. propose alternative algorithms,
- 3. execute candidates in isolated environments,
- 4. maintain a population of competing solvers,
- 5. detect plateaus, and
- 6. produce a validated production candidate.
- Potential applications include fleet routing, supply-chain planning, portfolio construction, production scheduling, and energy dispatch.
- Dependencies: The system would need robust problem modeling, reliable code execution, population-based search, reproducible evaluations, explainability, and safeguards against optimizing an incomplete or misleading objective.
- Large-scale logistics and supply-chain optimization
- Sector: Transportation, warehousing, retail, manufacturing.
- LLM-guided evolution could discover problem-specific heuristics for vehicle routing, container loading, inventory placement, and multi-stage scheduling.
- The paper’s full-program replacement strategy may be useful when improvements require changing the solver architecture—for example, combining neighborhood search with a learned repair heuristic rather than merely adjusting parameters.
- Dependencies: Industrial instances are larger, dynamic, and often expensive to evaluate. Candidate solutions also need to satisfy labor rules, delivery commitments, uncertainty constraints, and operational explainability requirements.
- Robotics motion planning and physical-space allocation
- Sector: Robotics and autonomous systems.
- Evolved solvers could optimize robot motion, multi-robot coordination, grasp selection, sensor placement, or packing of objects in constrained workspaces.
- Geometric verification principles from circle packing could be extended to collision checking and workspace safety.
- Dependencies: Real robots require guarantees under perception error, actuator uncertainty, timing constraints, and changing environments. Simulation-based improvements would need extensive hardware validation before deployment.
- Energy-system scheduling and infrastructure design
- Sector: Energy and utilities.
- The approach could generate heuristics for battery dispatch, renewable-energy integration, microgrid scheduling, charging-station placement, and transmission or facility layout.
- Plateau detection could help control expensive experimentation when candidate evaluations involve detailed power-flow or physical simulations.
- Dependencies: Energy applications require security, reliability, regulatory compliance, and robust optimization under uncertain demand and generation. A solver that performs well on historical benchmarks may fail under rare but critical conditions.
- Financial optimization and risk management
- Sector: Finance and insurance.
- Potential uses include portfolio rebalancing, collateral allocation, execution scheduling, and stress-test scenario selection.
- Independent verification could recompute risk measures, exposure limits, and regulatory constraints outside the generated solver.
- Dependencies: Financial objectives are nonstationary and sensitive to model assumptions. Generated algorithms would require extensive backtesting, out-of-sample evaluation, audit trails, human approval, and controls against unintended risk-taking.
- Healthcare scheduling and facility planning
- Sector: Healthcare operations.
- Candidate algorithms could improve operating-room scheduling, staff rostering, appointment allocation, ambulance positioning, and medical-device placement.
- The verifier pattern could enforce hard constraints such as staffing levels, capacity, and appointment compatibility.
- Dependencies: Healthcare applications involve patient safety, privacy, fairness, and legally or ethically significant trade-offs. Deployment would require human oversight and validation on representative operational data; the paper does not demonstrate clinical or healthcare performance.
- Population-based and multi-agent discovery systems
- Sector: AI research and automated science.
- The paper maintains one champion solver, but future systems could maintain multiple solver “islands,” preserve specialized candidates for different targets, and periodically exchange ideas.
- This could reduce premature convergence and support simultaneous optimization across heterogeneous instances.
- Dependencies: Population systems increase compute and evaluation costs and require selection mechanisms that prevent low-quality or redundant candidates from dominating. They also need provenance tracking so that successful innovations can be attributed and reproduced.
- Transfer of evolved algorithmic components across related problems
- Sector: Scientific computing and industrial software.
- Techniques such as structured initialization, defect migration, contact-graph refinement, and plateau detection could be stored as reusable algorithmic modules and transferred among related optimization tasks.
- A future library might automatically identify which components generalize from circle packing to sphere packing, layout, scheduling, or network design.
- Dependencies: Transferability is unproven. A heuristic that works for dense geometric packing may be ineffective or harmful in discrete or stochastic problems. Component reuse would require systematic ablation studies and problem-class benchmarks.
- Policy and public-sector resource allocation
- Sector: Government, urban planning, public infrastructure.
- Public agencies could use similar systems to explore bus scheduling, emergency-resource placement, school-capacity planning, land-use allocation, and infrastructure maintenance.
- Independent verification and archived iteration histories could support transparency and auditability.
- Dependencies: Public-sector objectives involve equity, legal constraints, stakeholder participation, and political accountability—not merely numerical optimization. Any deployment would require interpretable objectives, fairness analysis, public review, and human decision authority.
- Automated scientific discovery beyond optimization benchmarks
- Sector: Academia, materials science, computational biology, and physics.
- The architecture could eventually generate programs for simulation control, experimental design, symbolic construction, or hypothesis testing, provided each candidate has a reliable automated evaluation.
- The paper’s main methodological lesson is that inexpensive iterative search can expose useful algorithmic ideas when the problem description, feedback signal, and verifier are well designed.
- Dependencies: Scientific applications require stronger controls for false discoveries, data leakage, simulator mismatch, and irreproducible results. The demonstrated evidence supports algorithm discovery on a constrained benchmark, not yet autonomous scientific inference across open-ended domains.
Glossary
- Adaptive operator: A search operation whose behavior changes in response to observed performance or search conditions. “Sparse penalty + adaptive operators + elite pool”
- Affine lattice: A lattice transformed by linear operations and translation, used here to generate structured geometric configurations. “Affine lattice template bank”
- Basin hopping: A metaheuristic that alternates perturbations of a candidate solution with local optimization to explore multiple attraction basins. “The best solvers use combinations of penalty methods, basin-hopping metaheuristics, and linear programming for radii optimization.”
- Champion solver: The currently best-performing solver retained by an iterative optimization process. “The LLM proposes a complete replacement solver.”
- Combinatorial geometry: The study of geometric structures involving discrete objects and their arrangements. “The problem of packing circles in a container is a classical topic in combinatorial geometry”
- Combinatorial optimization: Optimization over configurations involving discrete or structurally distinct choices. “AlphaEvolve~\citep{alphaevolve2025} demonstrated that LLM-guided program evolution could discover state-of-the-art algorithms for combinatorial optimization”
- Contact graph: A graph representing which geometric objects touch or constrain one another. “Basin hopping with contact-graph polish (iter 1)”
- Constructive mathematics: Mathematics focused on explicitly building objects or solutions rather than merely proving their existence. “FunSearch~\citep{funsearch2024} similarly uses LLMs for program search but focuses on discovering mathematical constructions”
- Crossover: An evolutionary computation operation that combines characteristics of multiple candidate solutions. “Hexagonal lattice init + crossover”
- Defect migration: A packing heuristic that relocates problematic or weakly placed objects to alter and improve the configuration. “Defect migration (iter 12): removing weak circles, letting the packing re-equilibrate, then reinserting into new holes”
- Diminishing returns: A pattern in which additional computational effort produces progressively smaller improvements. “We implemented an early-stopping mechanism based on diminishing returns”
- Elite pool: A collection of the best candidate solutions retained to guide subsequent search. “Sparse penalty + adaptive operators + elite pool”
- Evolutionary controller: A mechanism that manages the generation, evaluation, selection, and modification of candidate programs. “A distributed evaluation pool, a carefully tuned evolutionary controller, and significant compute resources.”
- Feasibility shrink: A deliberate reduction of a numerical solution to ensure that it satisfies constraints despite floating-point errors. “Applies a strict feasibility shrink to eliminate numerical-precision artifacts”
- Formulation-space search: Exploration that changes the mathematical or computational representation of a problem, rather than only adjusting parameters. “Formulation-space search”
- Hexagonal lattice: A regular two-dimensional arrangement in which points or circles are organized in a hexagonal pattern. “Hexagonal lattice initialization (iter 4)”
- Independent verifier: A separate checking procedure that validates candidate outputs without sharing implementation code with the solver. “This is essential for credibility: the verifier shares no code with the solver”
- Island model: An evolutionary strategy that runs multiple semi-independent search populations and occasionally exchanges high-quality solutions. “Island-model parallelism (iter 5): independent basin-hopping chains on separate CPU cores with periodic migration of elite solutions.”
- KKT conditions: Necessary mathematical conditions for constrained optimization, named after Karush, Kuhn, and Tucker. “KKT-Newton exact polish”
- Local optimum: A solution better than nearby alternatives but not necessarily better than all feasible solutions. “For large , the landscape is highly non-convex with many local optima.”
- Local search: An optimization method that improves a solution by examining nearby candidate solutions. “new move operators, initialization strategies, local search enhancements”
- LLM: A neural LLM trained on large text collections that can generate and transform natural language and code. “We present Discovery Loop, a lightweight system that uses a LLM to iteratively evolve optimization algorithms.”
- Linear programming (LP): Optimization of a linear objective subject to linear equality or inequality constraints. “The best solvers use combinations of penalty methods, basin-hopping metaheuristics, and linear programming for radii optimization.”
- L-BFGS-B: A limited-memory quasi-Newton optimization algorithm that supports bound constraints. “a simple multi-start penalty L-BFGS-B solver with LP-optimal radii”
- Metaheuristic: A high-level search strategy designed to find good solutions to difficult optimization problems without guaranteeing global optimality. “a metaheuristic move that changes the combinatorial structure of the packing.”
- Mixed-integer programming (MIP): Optimization involving both continuous variables and integer or binary variables. “Our MIPLIB experiment (mixed-integer programming) had a 75\% failure rate in code generation”
- Non-convex: Describing an optimization landscape in which local optima may exist and standard convexity guarantees do not apply. “For large , the landscape is highly non-convex with many local optima.”
- Penalty method: An optimization technique that incorporates constraint violations into the objective through penalty terms. “The best solvers use combinations of penalty methods, basin-hopping metaheuristics, and linear programming for radii optimization.”
- Plateau detection: Identification of a period in which iterative optimization produces little or no improvement. “We implemented an early-stopping mechanism based on diminishing returns”
- Population: A set of candidate solutions maintained simultaneously in an evolutionary or population-based search method. “A population of solvers might enable more diverse exploration.”
- Ruin-and-recreate: A large-neighborhood search operation that removes part of a solution and reconstructs it, potentially producing an improved configuration. “Ruin-and-recreate LNS”
- Scoreboard: A structured record of candidate performance used to guide subsequent algorithm generation. “An LLM (Claude Fable 5.1) receives the current best solver, a scoreboard of results, and a history of ideas tried.”
- SLSQP: Sequential Least Squares Programming, a constrained nonlinear optimization algorithm based on sequential quadratic programming. “Basin hopping + SLSQP contact polish”
- Surrogate screening: Using an approximate predictive model to filter candidate solutions before applying more expensive evaluation. “Surrogate-screened basin hopping”
- Target instance: A specific parameterized version of an optimization problem used for evaluation. “Targets: ”
- Variable-radius circle packing: A geometric optimization problem in which circles may have different radii and must be arranged without overlap. “the csqv variant---packing circles with variable radii in the unit square to maximize the sum of radii”
- Zero-tolerance verification: Validation requiring exact constraint satisfaction within the adopted numerical checking procedure. “All results independently verified with zero tolerance and accepted by Packomania.”