exmex 0.8.1

Exmex is a fast, simple, and extendable mathematical expression evaluator.

# use std::error::Error;
# fn main() -> Result<(), Box<dyn Error>> {
#
use exmex::eval_str;
assert!((eval_str("1.5 * ((cos(0) + 23.0) / 2.0)")? - 18.0).abs() < 1e-12);
#
#     Ok(())
# }

For floats, we have a list of predifined operators containing ^, *, /, +, -, sin, cos, tan, exp, log, and log2. The full list is defined in make_default_operators.

Variables

For variables we can use strings that are not in the list of operators as shown in the following expression. Additionally, variables should consist only of letters, numbers, and underscores. More precisely, they need to fit the regular expression r"^[a-zA-Z_]+[a-zA-Z_0-9]*". Variables' values are passed as slices to eval.

# use std::error::Error;
# fn main() -> Result<(), Box<dyn Error>> {
#
use exmex::{make_default_operators, parse};
let to_be_parsed = "log(z) + 2* (-z^2 + sin(4*y))";
let expr = parse::<f64>(to_be_parsed, &make_default_operators::<f64>())?;
assert!((expr.eval(&[2.5, 3.7])? - 14.992794866624788 as f64).abs() < 1e-12);
#
#     Ok(())
# }

The n-th number in the slice corresponds to the n-th variable. Thereby only the first occurence of the variables is relevant. In this example, we have z=2.5 and y=3.7. If variables are between curly brackets, they can have arbitrary names, e.g., {456/549*(}, {x}, and confusingly even {x+y} are valid variable names as shown in the following.

# use std::error::Error;
# fn main() -> Result<(), Box<dyn Error>> {
#
use exmex::{make_default_operators, parse};
let x = 2.1f64;
let y = 0.1f64;
let to_be_parsed = "log({x+y})";  // {x+y} is the name of one(!) variable 😕.
let expr = parse::<f64>(to_be_parsed, &make_default_operators::<f64>())?;
assert!((expr.eval(&[x+y])? - 2.2f64.ln()).abs() < 1e-12);
#
#     Ok(())
# }

Extendability

Library users can define their own set of operators as shown in the following.

# use std::error::Error;
# fn main() -> Result<(), Box<dyn Error>> {
#
use exmex::{parse, BinOp, Operator};
let ops = [
Operator {
repr: "%",
bin_op: Some(BinOp{ apply: |a: i32, b: i32| a % b, prio: 1 }),
unary_op: None,
},
Operator {
repr: "/",
bin_op: Some(BinOp{ apply: |a: i32, b: i32| a / b, prio: 1 }),
unary_op: None,
},
];
let to_be_parsed = "19 % 5 / 2 / a";
let expr = parse::<i32>(to_be_parsed, &ops)?;
assert_eq!(expr.eval(&[1])?, 2);
#
#     Ok(())
# }

Operators

Operators are instances of the struct Operator that has its representation in the field repr, a binary and a unary operator of type Option<BinOp<T>> and Option<fn(T) -> T>, respectively, as members. BinOp contains in addition to the function pointer apply of type fn(T, T) -> T an integer prio. Operators can be both, binary and unary. See, e.g., - defined in the list of default operators. Note that we expect a unary operator to be always on the left of a number.

Data Types of Numbers

You can use any type that implements Copy and FromStr. In case the representation of your data type in the string does not match the number regex r"\.?[0-9]+(\.[0-9]+)?", you have to pass a suitable regex and use the function parse_with_number_pattern instead of parse. Here is an example for bool.

# use std::error::Error;
# fn main() -> Result<(), Box<dyn Error>> {
#
use exmex::{parse_with_number_pattern, BinOp, Operator};
let ops = [
Operator {
repr: "&&",
bin_op: Some(BinOp{ apply: |a: bool, b: bool| a && b, prio: 1 }),
unary_op: None,
},
Operator {
repr: "||",
bin_op: Some(BinOp{ apply: |a: bool, b: bool| a || b, prio: 1 }),
unary_op: None,
},
Operator {
repr: "!",
bin_op: None,
unary_op: Some(|a: bool| !a),
},
];
let to_be_parsed = "!(true && false) || (!false || (true && false))";
let expr = parse_with_number_pattern::<bool>(to_be_parsed, &ops, "true|false")?;
assert_eq!(expr.eval(&[])?, true);
#
#     Ok(())
# }

Priorities and Parentheses

In Exmex-land, unary operators always have higher priority than binary operators, e.g., -2^2=4 instead of -2^2=-4. Moreover, we are not too strict regarding parentheses. For instance "---1" will evalute to -1. If you want to be on the safe side, we suggest using parentheses.

Unicode

Unicode input strings are currently not supported 😕 but might be added in the future 😀.