Basin: Efficient and Extensible Numerical Optimization in Rust

Basin is a numerical optimization library for the Rust programming language (Matsakis & Klock, 2014). Numerical optimization is the task of finding the inputs that minimize a function, and it is a fundamental element across the sciences: fitting a model to data, calibrating a simulation, training a machine learning model, or choosing engineering parameters that minimize cost. Basin gives users a single, consistent way to both state and solve such problems, with a broad catalog of solvers and first-class support for constraints.

To use Basin, a user implements one or more small traits describing their objective—at minimum a CostFunction that returns a value for a given input, and optionally its derivatives (Gradient, Jacobian, or Hessian). The user then hands the problem, a solver, and a starting point to an Executor, which drives the optimization loop, handles stopping criteria, and returns the result. Basin works out of the box on plain Rust vectors and, optionally, with faster linear-algebra backends available behind feature flags. The default build compiles to WebAssembly, which means that Basin can be used in a browser without a native toolchain or BLAS/LAPACK support. Documentation is published at basin.rs, which includes a user guide, interactive visualizer, and a benchmark suite comparing Basin to other optimization libraries.

Statement of Need: Rust is increasingly used for scientific and numerical computing because it combines performance with memory safety and a strong package ecosystem. Optimization, however, is fragmented across the ecosystem: most crates specialize in a single family of methods and no widely used Rust crate couples a broad solver catalog with first-class constraints and a browser-ready default build. Basin was written to close that gap, and it targets four concrete needs.

First, Basin includes a broad catalog of solvers. Real problems rarely announce in advance what optimization algorithm they need, so Basin includes a large set of solvers behind a single, consistent API. The catalog includes:

• first-order and quasi-Newton methods (gradient descent, SGD, BFGS, L-BFGS, L-BFGS-B, and a Newton trust-region method) (Byrd et al., 1995; Nocedal & Wright, 2006; Zhu et al., 1997);

• derivative-free methods (Nelder–Mead (Nelder & Mead, 1965), one-dimensional Brent (Brent, 2013) and golden-section searches, NEWUOA (Powell, 2006), BOBYQA (Powell, 2009), LINCOA (Powell, 2015), COBYLA (Powell, 1994), and mesh adaptive direct search (Audet & Dennis, 2006));

• nonlinear least squares (Gauss–Newton and Levenberg–Marquardt (Nielsen, 1999));

• global and stochastic methods (random search (Brooks, 1958), CMA-ES (Hansen, 2016), differential evolution (Storn & Price, 1997), a steady-state genetic algorithm (Molina et al., 2010), and basin-hopping (Wales & Doye, 1997)); and

• memetic combinations (MA-LS-Chain (Molina et al., 2010), plus CMA-ES and differential evolution injection wrappers).

Switching methods is simple, sometimes requiring changing only a single line of code.

Second, the design enforces correctness at compile time. Solvers, termination criteria, and observers in Basin bind on the minimum state shape they require, which means that a method that exposes no gradient cannot be paired with a gradient-based stopping rule—mismatches yield compilation errors rather than runtime failures.

Third, Basin is designed to be portable. The default build targets WebAssembly with neither BLAS/LAPACK nor concurrency dependencies, which means that Basin can be run in a browser without a native toolchain. It also supports a low minimum supported Rust version in order to facilitate its use in R packages and other scientific programming languages that can be extended through Rust.

Fourth, support for constraints is first-class. Constraints are declared on the problem, not passed to the solver call, and a solver that requires constraints will not accept an unconstrained problem—again a compile error rather than a runtime one. Basin supports box bounds, linear equality and inequality constraints, and nonlinear inequality constraints, together with opt-in adapters (log-barrier and augmented Lagrangian) that recast a constrained problem as an unconstrained one so that any unconstrained solver can be applied to it.

The target audience is researchers, engineers, and students who need reliable optimization in Rust or any of the scientific programming languages that can be easily extended through Rust, such as R, Julia, and Python.

State of the Field: The closest analog to Basin is argmin (Kroboth, 2018/2025): a numerical optimization framework from which Basin takes considerable inspiration, including the Executor driver loop, the Solver/Problem trait split, and per-solver State. But Basin diverges elsewhere, bringing:

• first-class, problem-side constraints rather than solver configuration,

• a richer linear-algebra tier implemented in pure Rust, and

• generic termination criteria shared between solvers.

gomez (Nevyhoštěný, 2021/2025) is another Rust crate with similar scope, implementing a small set of derivative-free methods and nonlinear least-squares solvers, and supporting constraints. Compared to Basin, it has a smaller solver catalog, only supports box constraints, and does not have a generic backend tier for linear algebra.

Finally, the nlopt crate provides a Rust interface to the NLopt C library (Johnson & Schueller, 2013/2026). Although NLopt has a broad catalog of solvers, it requires a C toolchain to build and is not WebAssembly-compatible. It also lacks Basin’s generic termination criteria and first-class constraints support.

In summary, Basin’s contribution is to bring a broad catalog natively to Rust and WebAssembly, without linking a C or Fortran toolchain in its default configuration.

Software Design: Basin is organized as a generic core with a broad catalog of solvers layered on top of it. The design is built on a set of principles that we think make it easy to extend and maintain.

Tiered Backends: Parameters and linear algebra are generic over the backend. A universal vector tier (operations such as scaled addition, dot products, and norms that every backend implements well) keeps first-order and derivative-free solvers backend-generic across Vec, nalgebra (Crozet, 2013/2026), ndarray (Sverdrup & Turner, 2014/2026), and faer (Sarrazin, 2022/2026). Each backend is activated via a single Cargo feature pinning one major version and a backend major-version bump becomes a Basin major-version bump. This differs from argmin, which uses versioned backend traits and requires a new trait for each backend version. We opted to keep the backend traits versionless and instead version the entire crate in order to improve maintainability.

Compile-Time Correctness: Generic stopping conditions (iteration limits, tolerance families, evaluation budgets, and wall-clock limits) are configured uniformly on the Executor rather than reimplemented per solver, and each criterion binds on the minimum state shape it needs. This is what makes an ill-typed pairing (a gradient tolerance on a gradient-free method) a compile error. The cost of this is more complex generic signatures, but the benefit is that Basin users can be confident that their stopping criteria are compatible with their solver and problem.

Constraints: Constraints describe the problem, so in Basin they exist as problem-side traits rather than in executor configuration or on the state. Solvers declare the constraints they consume through those traits, which means that an unconstrained problem handed to a solver that requires constraints does not compile. For the common case of reusing an unconstrained solver, opt-in adapters (a log-barrier method and an augmented-Lagrangian method) wrap the problem; each adapter consumes the constraint trait and exposes only CostFunction and Gradient, which is precisely what routes a constrained problem onto an unconstrained solver.

Compatibility: Basin is WebAssembly-compatible by default. Parallelism and BLAS/LAPACK integration are opt-in features, and default paths use a WebAssembly-safe time shim and a seedable, WebAssembly-safe random number generator. The minimum supported Rust version is kept deliberately low in order to comply with the toolchain requirements of the R package network CRAN in order to facilitate Basin’s use in R packages such as eulerr.

Scalar Generics: The interface is generic over the scalar type, with f64 as the default so existing call sites resolve unchanged, while f32 works across states, solvers, termination criteria, and the math layer.

Research Impact Statement: Basin is used as the optimizer for the Rust library Eunoia (Larsson & Gustafsson, 2026), which in turn is used in the R package eulerr (Larsson & Gustafsson, 2018). It is also used in the R package balancing (Barrett, 2026), which calculates optimization-based balancing weights for causal inference. Benchmarks against competitors are available at basin.rs, showing that Basin generally outperforms argmin and nlopt and is on par with gomez. At the time of writing, the crate has been downloaded roughly 30,000 times on https://crates.io/crates/basin over the last three months and has been featured in This Week in Rust (Arlynx, 2026).

AI Usage Disclosure: Generative AI tools were used substantially during the development of Basin: Claude Code, running Claude Opus 4.8, Claude Opus 5, and Fable 5, was used for code generation and refactoring, writing unit tests, writing documentation, and reviewing this manuscript. The author made all core design decisions—the architecture, the design tenets, and the API—and reviewed, edited, and validated all AI-assisted contributions. In order to further verify correctness, the Powell-family solvers were developed against PRIMA (Zhang, 2020/2023) and cross-validated against it numerically, and the L-BFGS-B implementation was checked for numerical agreement with the original Fortran code (Zhu et al., 1997). The remaining solvers are covered by a test suite problems.

Acknowledgements: Basin owes a substantial intellectual debt to argmin (Kroboth, 2018/2025). The Powell-family derivative-free solvers are derived from PRIMA (Zhang, 2020/2023), Zaikun Zhang’s modern-Fortran reference implementation of M. J. D. Powell’s methods, used as the authoritative source for the exact formulas and as a cross-validation oracle. The bound-constrained L-BFGS-B solver is a port of the L-BFGS-B version 3.0 Fortran code by Ciyou Zhu, Richard H. Byrd, Peihuang Lu, and Jorge Nocedal, with the improvements by José Luis Morales and Jorge Nocedal (Morales & Nocedal, 2011). Both are distributed under the BSD 3-Clause License, and their notices are retained in the Basin source tree.

Based on the paper, here are specific improvements to AI systems and what the improved systems can do:

1. Compile-Time Correctness for AI Pipelines

• Improvement: Adopt Basin’s pattern of binding algorithms to minimum required state shapes (e.g., gradient-based stopping criteria cannot be used with gradient-free solvers) at compile time. Apply this to AI model training and hyperparameter optimization pipelines.

• Improved AI system: An AI system that automatically rejects invalid configurations (e.g., using a Hessian-based optimizer on a non-differentiable model) before execution, eliminating runtime failures and reducing debugging time in production ML systems.

2. First-Class Constraint Handling in Optimization

• Improvement: Integrate problem-side constraint traits (box bounds, linear/nonlinear equality/inequality) directly into AI training loops, with automatic adapters (log-barrier, augmented Lagrangian) to convert constrained problems into unconstrained ones.

• Improved AI system: An AI system that can natively optimize models under hard constraints (e.g., resource limits, safety bounds, fairness constraints) without manual penalty tuning, enabling safe deployment of RL agents or control systems with guaranteed constraint satisfaction.

3. WebAssembly-Native Optimization for Edge AI

• Improvement: Port Basin’s WebAssembly-compatible, BLAS/LAPACK-free default build to AI inference and training modules, enabling optimization routines to run in browsers and edge devices without native toolchains.

• Improved AI system: An AI system that can perform on-device model calibration, hyperparameter tuning, or few-shot adaptation directly in a browser or IoT device, reducing cloud dependency and latency for personalized AI applications.

4. Generic Termination Criteria for Adaptive AI Training

• Improvement: Implement Basin’s uniform, generic stopping criteria (iteration limits, tolerance families, evaluation budgets, wall-clock limits) across AI training loops, with criteria binding to the minimum state shape they need.

• Improved AI system: An AI system that automatically stops training when convergence is achieved based on multiple, configurable criteria (e.g., gradient norm, loss plateau, time budget), preventing overfitting and reducing computational waste in large-scale model training.

5. Tiered Backend Abstraction for AI Frameworks

• Improvement: Adopt Basin’s tiered backend design (universal vector operations across Vec, nalgebra, ndarray, faer) to decouple AI algorithms from specific linear algebra libraries.

• Improved AI system: An AI framework that can seamlessly switch between CPU, GPU, and specialized hardware backends without code changes, improving portability and performance across heterogeneous computing environments.

6. Memetic and Hybrid Optimization for AI Model Selection

• Improvement: Integrate Basin’s memetic combinations (e.g., MA-LS-Chain, CMA-ES with differential evolution injection) into AI hyperparameter search and neural architecture search.

• Improved AI system: An AI system that combines global exploration (e.g., CMA-ES) with local refinement (e.g., gradient descent) to find better model architectures and hyperparameters faster than single-method approaches, improving final model accuracy.

7. Scalar Generics for Mixed-Precision AI

• Improvement: Use Basin’s scalar generics (f64 default, f32 support) to enable mixed-precision training and inference in AI systems.

• Improved AI system: An AI system that can automatically switch between f64 and f32 precision based on task requirements (e.g., f64 for scientific simulation, f32 for edge inference), optimizing memory usage and speed without sacrificing accuracy where needed.

8. Benchmark-Driven Solver Selection

• Improvement: Leverage Basin’s benchmark suite (comparing against argmin, nlopt, gomez) to build an AI meta-optimizer that selects the best solver for a given problem type.

• Improved AI system: An AI system that automatically recommends and applies the most efficient optimization algorithm for a given task (e.g., derivative-free for black-box, L-BFGS for smooth, CMA-ES for global), reducing user expertise requirements and improving optimization performance across diverse problems.

Basin is a numerical optimization library for the Rust programming language. Numerical optimization is the task of finding the inputs that minimize a function, and it is a fundamental element across the sciences: fitting a model to data, calibrating a simulation, training a machine learning model, or choosing engineering parameters that minimize cost. Basin gives users a single, consistent way to both state and solve such problems, with a broad catalog of solvers and first-class support for constraints.