Mathematical optimization in pure Rust
argmin is a numerical optimization toolbox/framework written entirely in Rust. This crate is looking for contributors!
Documentation of most recent release
argmin aims at offering a wide range of optimization algorithms with a consistent interface, written purely in Rust. It comes with additional features such as checkpointing and observers which for instance allow one to log the progress of an optimization to screen or file.
In addition it provides a framework for implementing iterative optimization algorithms in a convenient manner. Essentially, a single iteration of the algorithm needs to be implemented and everything else, such as handling termination, parameter vectors, gradients and Hessians, is taken care of by the library.
This library makes heavy use of generics in order to be as type-agnostic as possible. It supports
nalgebraand
ndarraytypes via feature gates, but custom types can easily be made compatible with argmin by implementing the respective traits.
Future plans include functionality for easy performance evaluation of optimization algorithms, parallel computation of cost functions/gradients/Hessians as well as GPU support And of course more optimization algorithms!
This crate is looking for contributors! Potential projects can be found in the Github issues, but even if you have an idea that is not already mentioned there or if you found a bug, feel free to open a new issue. Besides adding optimization methods and new features, other contributions are also highly welcome, for instance improving performance, documentation, writing examples (with real world problems), developing tests, adding observers, implementing a C interface or Python wrappers.
Add this to your
Cargo.toml:
[dependencies] argmin = "0.4.7"
There are additional features which can be activated in
Cargo.toml:
[dependencies] argmin = { version = "0.4.7", features = ["ctrlc", "ndarrayl", "nalgebral"] }
These may become default features in the future. Without these features compilation to
wasm32-unknown-unkownseems to be possible.
ctrlc: Uses the
ctrlccrate to properly stop the optimization (and return the current best result) after pressing Ctrl+C.
ndarrayl: Support for
ndarray,
ndarray-linalgand
ndarray-rand.
nalgebral: Support for
nalgebra.
Using the
ndarraylfeature on Windows might require to explicitly choose the
ndarray-linalgBLAS backend in the
Cargo.toml:
ndarray-linalg = { version = "*", features = ["intel-mkl-static"] }
When compiling to WASM, one of the following features must be used:
argmin = { version = "0.4.7", features = ["wasm-bindgen"] }
argmin = { version = "0.4.7", features = ["stdweb"] }
Note that WASM support is still experimental. Please report any issues you encounter when compiling argmin to WASM.
Running the tests requires the
ndarrayland feature to be enabled:
cargo test --features "ndarrayl"
The examples require all features to be enabled:
cargo test --features --all-features
A problem can be defined by implementing the
ArgminOptrait which comes with the associated types
Param,
Outputand
Hessian.
Paramis the type of your parameter vector (i.e. the input to your cost function),
Outputis the type returned by the cost function,
Hessianis the type of the Hessian and
Jacobianis the type of the Jacobian. The trait provides the following methods:
apply(&self, p: &Self::Param) -> Result<:output error>: Applys the cost function to parameters
pof type
Self::Paramand returns the cost function value.
gradient(&self, p: &Self::Param) -> Result<:param error>: Computes the gradient at
p.
hessian(&self, p: &Self::Param) -> Result<:hessian error>: Computes the Hessian at
p.
jacobian(&self, p: &Self::Param) -> Result<:jacobian error>: Computes the Jacobian at
p.
The following code snippet shows an example of how to use the Rosenbrock test functions from
argmin-testfunctionsin argmin:
use argmin_testfunctions::{rosenbrock_2d, rosenbrock_2d_derivative, rosenbrock_2d_hessian}; use argmin::prelude::*;/// First, create a struct for your problem struct Rosenbrock { a: f64, b: f64, }
/// Implement
ArgminOp
forRosenbrock
impl ArgminOp for Rosenbrock { /// Type of the parameter vector type Param = Vec; /// Type of the return value computed by the cost function type Output = f64; /// Type of the Hessian. Can be()
if not needed. type Hessian = Vec>; /// Type of the Jacobian. Can be()
if not needed. type Jacobian = (); /// Floating point precision type Float = f64;/// Apply the cost function to a parameter `p` fn apply(&self, p: &Self::Param) -> Result<:output error> { Ok(rosenbrock_2d(p, self.a, self.b)) } /// Compute the gradient at parameter `p`. fn gradient(&self, p: &Self::Param) -> Result<:param error> { Ok(rosenbrock_2d_derivative(p, self.a, self.b)) } /// Compute the Hessian at parameter `p`. fn hessian(&self, p: &Self::Param) -> Result<:hessian error> { let t = rosenbrock_2d_hessian(p, self.a, self.b); Ok(vec![vec![t[0], t[1]], vec![t[2], t[3]]]) }
} </:hessian></:param></:output>
It is optional to implement any of these methods, as there are default implementations which will return an
Errwhen called. What needs to be implemented is defined by the requirements of the solver that is to be used.
The following example shows how to use the previously shown definition of a problem in a Steepest Descent (Gradient Descent) solver.
use argmin::prelude::*; use argmin::solver::gradientdescent::SteepestDescent; use argmin::solver::linesearch::MoreThuenteLineSearch;// Define cost function (must implement
ArgminOperator
) let cost = Rosenbrock { a: 1.0, b: 100.0 };// Define initial parameter vector let init_param: Vec = vec![-1.2, 1.0];
// Set up line search let linesearch = MoreThuenteLineSearch::new();
// Set up solver let solver = SteepestDescent::new(linesearch);
// Run solver let res = Executor::new(cost, solver, init_param) // Add an observer which will log all iterations to the terminal .add_observer(ArgminSlogLogger::term(), ObserverMode::Always) // Set maximum iterations to 10 .max_iters(10) // run the solver on the defined problem .run()?;
// print result println!("{}", res);
Argmin offers an interface to observe the state of the iteration at initialization as well as after every iteration. This includes the parameter vector, gradient, Hessian, iteration number, cost values and many more as well as solver-specific metrics. This interface can be used to implement loggers, send the information to a storage or to plot metrics. Observers need to implment the
Observetrait. Argmin ships with a logger based on the
slogcrate.
ArgminSlogLogger::termlogs to the terminal and
ArgminSlogLogger::filelogs to a file in JSON format. Both loggers also come with a
*_noblockversion which does not block the execution of logging, but may drop some messages if the buffer is full. Parameter vectors can be written to disc using
WriteToFile. For each observer it can be defined how often it will observe the progress of the solver. This is indicated via the enum
ObserverModewhich can be either
Always,
Never,
NewBest(whenever a new best solution is found) or
Every(i)which means every
ith iteration.
let res = Executor::new(problem, solver, init_param) // Add an observer which will log all iterations to the terminal (without blocking) .add_observer(ArgminSlogLogger::term_noblock(), ObserverMode::Always) // Log to file whenever a new best solution is found .add_observer(ArgminSlogLogger::file("solver.log", false)?, ObserverMode::NewBest) // Write parameter vector to `params/param.arg` every 20th iteration .add_observer(WriteToFile::new("params", "param"), ObserverMode::Every(20)) // run the solver on the defined problem .run()?;
The probability of crashes increases with runtime, therefore one may want to save checkpoints in order to be able to resume the optimization after a crash. The
CheckpointModedefines how often checkpoints are saved and is either
Never(default),
Always(every iteration) or
Every(u64)(every Nth iteration). It is set via the setter method
checkpoint_modeof
Executor. In addition, the directory where the checkpoints and a prefix for every file can be set via
checkpoint_dirand
checkpoint_name, respectively.
The following example shows how the
from_checkpointmethod can be used to resume from a checkpoint. In case this fails (for instance because the file does not exist, which could mean that this is the first run and there is nothing to resume from), it will resort to creating a new
Executor, thus starting from scratch.
let res = Executor::from_checkpoint(".checkpoints/optim.arg", Rosenbrock {}) .unwrap_or(Executor::new(Rosenbrock {}, solver, init_param)) .max_iters(iters) .checkpoint_dir(".checkpoints") .checkpoint_name("optim") .checkpoint_mode(CheckpointMode::Every(20)) .run()?;
In this section we are going to implement the Landweber solver, which essentially is a special form of gradient descent. In iteration
k, the new parameter vector
x_{k+1}is calculated from the previous parameter vector
x_kand the gradient at
x_kaccording to the following update rule:
x_{k+1} = x_k - omega * \nabla f(x_k)
In order to implement this using the argmin framework, one first needs to define a struct which holds data specific to the solver. Then, the
Solvertrait needs to be implemented for the struct. This requires setting the associated constant
NAMEwhich gives your solver a name. The
next_itermethod defines the computations performed in a single iteration of the solver. Via the parameters
opand
stateone has access to the operator (cost function, gradient computation, Hessian, ...) and to the current state of the optimization (parameter vectors, cost function values, iteration number, ...), respectively.
use argmin::prelude::*; use serde::{Deserialize, Serialize};// Define a struct which holds any parameters/data which are needed during the execution of the // solver. Note that this does not include parameter vectors, gradients, Hessians, cost // function values and so on, as those will be handled by the
Executor
. #[derive(Serialize, Deserialize)] pub struct Landweber { /// omega omega: F, }impl Landweber { /// Constructor pub fn new(omega: F) -> Self { Landweber { omega } } }
impl Solver for Landweber where //
O
always needs to implementArgminOp
O: ArgminOp, //O::Param
needs to implementArgminScaledSub
because of the update formula O::Param: ArgminScaledSub<:param o::float o::param>, F: ArgminFloat, { // This gives the solver a name which will be used for logging const NAME: &'static str = "Landweber";// Defines the computations performed in a single iteration. fn next_iter( &mut self, // This gives access to the operator supplied to the `Executor`. `O` implements // `ArgminOp` and `OpWrapper` takes care of counting the calls to the respective // functions. op: &mut OpWrapper<o>, // Current state of the optimization. This gives access to the parameter vector, // gradient, Hessian and cost function value of the current, previous and best // iteration as well as current iteration number, and many more. state: &IterState<o>, ) -> Result<argminiterdata>, Error> { // First we obtain the current parameter vector from the `state` struct (`x_k`). let xk = state.get_param(); // Then we compute the gradient at `x_k` (`\nabla f(x_k)`) let grad = op.gradient(&xk)?; // Now subtract `\nabla f(x_k)` scaled by `omega` from `x_k` to compute `x_{k+1}` let xkp1 = xk.scaled_sub(&self.omega, &grad); // Return new paramter vector which will then be used by the `Executor` to update // `state`. Ok(ArgminIterData::new().param(xkp1)) }
} </:param>
Licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.