Skip to content

v4.0.0

Choose a tag to compare

View all tags
@shashi shashi released this 26 Sep 07:02
· 125 commits to master since this release
v4.0.0
1923e4d
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

SymbolicUtils v4.0.0

Diff since v3.32.0

Breaking changes

SymbolicUtils has undergone a major refactor aimed at improving performance and type stability.

Use of Moshi.jl

The internal data structure for a BasicSymbolic is updated to use Moshi.jl for the sum type instead of Unityper. The type alias BasicSymbolic is still provided. The Moshi.Match.@match macro should be used to pattern match variants.

New variant structure

The following variants are retained from v3:

  • Sym
  • Term
  • Div

Add and Mul have been merged into one AddMul variant with the same structure. The field variant::AddMulVariant.T is used to differentiate between them. AddMulVariant is an enum from EnumX.jl. The old Pow term has been deprecated, and is replaced by a Term.

The Const variant has been added. Any constants (non-symbolic values) in expressions are now wrapped in a Const variant for type-stability. Thus, tree operations such as arguments, substitute will now return (arrays of) BasicSymbolic. The function unwrap_const can be used to obtain the value inside a Const. It acts as the identity function if given a non-Const value. Consts are printed in blue in the REPL, to avoid ambiguity with true literal values.

All variants now have a shape field. This allows first-class support for symbolic arrays. SymbolicUtils now implements an array algebra. Arrays of symbolics are now represented as a Term with hvncat as the operation. The shape of a symbolic or non-symbolic value can be obtained with the shape function. SymbolicUtils.promote_shape is a new interface function that returns the shape of the result of an operation, given the operation and the shape(s) of its argument(s).

The ArrayOp variant has been added to represent tensor-contraction-like operations. See the docstring for @arrayop for more information.

Change of symtype representation and new vartype

The symtype of a symbolic variable is no longer stored in type information. It is now present in the type field of a variant. This allows storing the entire tree in a type-stable manner and considerably improves inference and precompile-friendliness of symbolic code.

BasicSymbolic{T} is now used to represent the form of algebra to use when manipulating symbolic variables. T can take the following values:

  • SymReal: The default, expected form of symbolic algebra.
  • SafeReal: Identical to SymReal, except that identical terms in the numerator and denominator of an expression are not cancelled.
  • TreeReal: Does not assume associativity or commutativity of operations. All operations are represented using the Term structure.

This is known as the vartype of a symbolic variable. Note that a tree must be pure - it cannot contain symbolic variables with different vartypes. The vartype can be specified in the @syms macro by using vartype=Value as the last argument to it. For example, @syms a b c vartype=SafeReal.

Removal of Symbolic

SymbolicUtils no longer allows defining custom Symbolic subtypes. The Symbolic type has been removed. This allows much greater performance by concretely typing the entire symbolic tree structure. As required, additional variants may be added to BasicSymbolic in the future.

Removal of PolyForm

PolyForm is now removed. The function to_poly! should be used to convert a symbolic tree into a DynamicPolynomials.Polynomial. The function from_poly provides the reverse transformation.

Merged pull requests:

Contributors

fkastner and AayushSabharwal
Assets 2
Loading