in its current implementation, the memoization of AdaptableModifier can be infinite, which is something we want to avoid

add a fast-matching Modifier that can have dynamically added patterns. this is useful for easily customizing functionality while maintaining speed.

This crate would ideally not require a memory allocator.

because rules are applied bottom-up and are frequently repeated on the same inputs, doing memoization on modify could create massive speed improvements

this should also fix the errors with function parsing

simplifier() works on x - x = 0, but not sin(x) - sin(x) = 0,. This should not occur as the pattern matches _*1 - _*1 → 0.

MultiKeyBinarySearchTree isn't an incredibly efficient way of storing and retrieving (Expression, Function) pairs, so a replacement could be useful.

Example code should either be moved to an examples directory or be expanded on to create a more full featured application.
Not urgent, can be left as is for beta/pre-release purposes, but should be done before an actual release.

this is a tracking issue for the potential name changes for this project

• fruit themed:
  • lemonlime
  • limecas
  • lemoncas (this is the one I'm leaning towards)
  • citrus-cas

the output of fmt::Display for Expression is broken (Expression won't print in a way that can be reinterpreted by the parser). the associated test is test_fmt_parse.

Reasoning

Having separate steps that specifically handle only symbolic and numerical computation is very limiting. The current plan wouldn't allow for partial evaluation of functions

>>> y = 2
>>> f(x, y) = x ^ 2 + y ^ 2

would return undefined with the current plan for the evaluator and approximator stages.

Proposed solution

Change the behavior of the evaluator to act like both the current evaluator and the approximator, removing the need for an approximator in the first place. The modify function would now return a (Expression, Option<Expression>) where the left value would be the simplest form while the right value would be an approximated form. If both are equal, then the right value would be a None, otherwise, it will hold the approximated value.

This would make the below examples of partial evaluation to become possible

>>> y = 1
>>> z = 1
>>> <x, y, z> dot <2, 2, 2>
(2 * x + 2 * y + 2 * z, Some(2 * x + 4))

>>> y = 2
>>> x ^ 2 + diff(y ^ 2, y)
(x ^ 2 + 2 * y, Some(x ^ 2 + 4))

while also in the long term, allowing for the functionality seen here where the exact form is returned but an approximate form is also given

This method could also allow for multiple fallbacks, such as if an integral is unable to be found symbolically, then the evaluator could fall back onto the approximated form of the integral (through various numeric integration methods such trapezoid, midpoint, simpsons, gauss legendre, gauss konrod, clenshaw curtis) to continue the evaluation.

tests in different modules overlap in some areas, which should be separated or integrative. additionally, many test cases are not covered by the existing tests.

because of the way functions are parsed, it's not possible to input a function that has no arguments

add a map that approximates core functions like sin, cos, tan, etc.