diff --git a/README.md b/README.md index f0b46bbf..0d7b1366 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ Octonian algebras, you've come to the right place. [Symbols in SymbolicUtils](https://symbolicutils.juliasymbolics.org/#creating_symbolic_expressions) carry type information. Operations on them propagate this information. [A rule-based rewriting language](https://symbolicutils.juliasymbolics.org/rewrite/#rule-based_rewriting) can be used to find subexpressions that satisfy arbitrary conditions and apply arbitrary transformations on the matches. The library also contains a set of useful [simplification](https://juliasymbolics.github.io/SymbolicUtils.jl/#simplification) rules for expressions of numeric symbols and numbers. These can be remixed and extended for special purposes. -If you are a Julia package develper in need of a rule rewriting system for your own types, have a look at the [interfacing guide](https://symbolicutils.juliasymbolics.org/interface/). +If you are a Julia package developer in need of a rule rewriting system for your own types, have a look at the [interfacing guide](https://symbolicutils.juliasymbolics.org/interface/). ### "I don't want to read your manual, just show me some cool code" diff --git a/docs/src/manual/representation.md b/docs/src/manual/representation.md index 1c8dde52..b0b1585d 100644 --- a/docs/src/manual/representation.md +++ b/docs/src/manual/representation.md @@ -2,7 +2,7 @@ Performance of symbolic simplification depends on the datastructures used to represent terms. Efficient datastructures often have the advantage of automatic simplification, and of efficient storage. -The most basic term representation simply holds a function call and stores the function and the arguments it is called with. This is done by the `Term` type in SymbolicUtils. Functions that aren't commutative or associative, such as `sin` or `hypot` are stored as `Term`s. Commutatative and associative operations like `+`, `*`, and their supporting operations like `-`, `/` and `^`, when used on terms of type `<:Number`, stand to gain from the use of more efficient datastrucutres. +The most basic term representation simply holds a function call and stores the function and the arguments it is called with. This is done by the `Term` type in SymbolicUtils. Functions that aren't commutative or associative, such as `sin` or `hypot` are stored as `Term`s. Commutative and associative operations like `+`, `*`, and their supporting operations like `-`, `/` and `^`, when used on terms of type `<:Number`, stand to gain from the use of more efficient datastrucutres. All term representations must support `operation` and `arguments` functions. And they must define `istree` to return `true` when called with an instance of the type. Generic term-manipulation programs such as the rule-based rewriter make use of this interface to inspect expressions. In this way, the interface wins back the generality lost by having a zoo of term representations instead of one. (see [interface](/interface/) section for more on this.) @@ -16,7 +16,7 @@ Similarly, $x_1^{m_1}x_2^{m_2}...x_{m_n}$ is represented by Note that `Add` and `Mul` types perform a preliminary simplification which suffices to simplify numeric expressions to a large extent during construction. -$p / q$ is represented by `Div(p, q)`. The result of `*` on `Div` is maintainted as a `Div`. For example, `Div(p_1, q_1) * Div(p_2, q_2)` results in `Div(p_1 * p_2, q_1 * q_2)` and so on. The effect is, in `Div(p, q)`, `p` or `q` or, if they are Mul, any of their multiplicands is not a Div. So `Mul`s must always be nested inside a `Div` and can never show up immediately wrapping it. This rule sets up an expression so that it helps the `simplify_fractions` procedure described two sections below. +$p / q$ is represented by `Div(p, q)`. The result of `*` on `Div` is maintained as a `Div`. For example, `Div(p_1, q_1) * Div(p_2, q_2)` results in `Div(p_1 * p_2, q_1 * q_2)` and so on. The effect is, in `Div(p, q)`, `p` or `q` or, if they are Mul, any of their multiplicands is not a Div. So `Mul`s must always be nested inside a `Div` and can never show up immediately wrapping it. This rule sets up an expression so that it helps the `simplify_fractions` procedure described two sections below. ### Polynomial representation diff --git a/docs/src/manual/rewrite.md b/docs/src/manual/rewrite.md index 5397fbbe..c1be3187 100644 --- a/docs/src/manual/rewrite.md +++ b/docs/src/manual/rewrite.md @@ -74,7 +74,7 @@ Notice that the expression was autosimplified before application of the rule. Matcher pattern may contain slot variables with attached predicates, written as `~x::f` where `f` is a function that takes a matched expression and returns a boolean value. Such a slot will be considered a match only if `f` returns true. -Similarly `~~x::g` is a way of attaching a predicate `g` to a segment variable. In the case of segment variables `g` gets a vector of 0 or more expressions and must return a boolean value. If the same slot or segment variable appears twice in the matcher pattern, then at most one of the occurance should have a predicate. +Similarly `~~x::g` is a way of attaching a predicate `g` to a segment variable. In the case of segment variables `g` gets a vector of 0 or more expressions and must return a boolean value. If the same slot or segment variable appears twice in the matcher pattern, then at most one of the occurrence should have a predicate. For example, @@ -133,7 +133,7 @@ acpyid = @acrule sin(~x)^2 + cos(~x)^2 => 1 acpyid(cos(x)^2 + sin(x)^2 + 2cos(x)*sin(x)) ``` -It has been some work. Fortunately rules may be [chained together](#chaining rewriters) into more sophisticated rewirters to avoid manual application of the rules. +It has been some work. Fortunately rules may be [chained together](#chaining rewriters) into more sophisticated rewriters to avoid manual application of the rules. ## Composing rewriters diff --git a/page/config.md b/page/config.md index 4b179402..c24f6048 100644 --- a/page/config.md +++ b/page/config.md @@ -114,7 +114,7 @@ NOTE: "github" or "atom-one-dark"; use lower case and replace spaces with `-`. - code_border_radius: how rounded the corners of code blocks should be - - code_output_indent: how much left-identation to add for "output blocks" + - code_output_indent: how much left-indentation to add for "output blocks" (results of the evaluation of code blocks), use 0 if you don't want indentation. --> diff --git a/page/interface.md b/page/interface.md index 894ddd82..88a77c80 100644 --- a/page/interface.md +++ b/page/interface.md @@ -22,7 +22,7 @@ with SymbolicUtils.jl Check if `x` represents an expression tree. If returns true, it will be assumed that `operation(::T)` and `arguments(::T)` -methods are defined. Definining these three should allow use +methods are defined. Defining these three should allow use of `simplify` on custom types. Optionally `symtype(x)` can be defined to return the expected type of the symbolic expression. diff --git a/page/representation.md b/page/representation.md index b8932b5f..aa07ee4a 100644 --- a/page/representation.md +++ b/page/representation.md @@ -2,7 +2,7 @@ Performance of symbolic simplification depends on the datastructures used to represent terms. Efficient datastructures often have the advantage of automatic simplification, and of efficient storage. -The most basic term representation simply holds a function call and stores the function and the arguments it is called with. This is done by the `Term` type in SymbolicUtils. Functions that aren't commutative or associative, such as `sin` or `hypot` are stored as `Term`s. Commutatative and associative operations like `+`, `*`, and their supporting operations like `-`, `/` and `^`, when used on terms of type `<:Number`, stand to gain from the use of more efficient datastrucutres. +The most basic term representation simply holds a function call and stores the function and the arguments it is called with. This is done by the `Term` type in SymbolicUtils. Functions that aren't commutative or associative, such as `sin` or `hypot` are stored as `Term`s. Commutative and associative operations like `+`, `*`, and their supporting operations like `-`, `/` and `^`, when used on terms of type `<:Number`, stand to gain from the use of more efficient datastrucutres. All term representations must support `operation` and `arguments` functions. And they must define `istree` to return `true` when called with an instance of the type. Generic term-manipulation programs such as the rule-based rewriter make use of this interface to inspect expressions. In this way, the interface wins back the generality lost by having a zoo of term representations instead of one. (see [interface](/interface/) section for more on this.) @@ -16,7 +16,7 @@ Similarly, $x_1^{m_1}x_2^{m_2}...x_{m_n}$ is represented by Note that `Add` and `Mul` types perform a preliminary simplification which suffices to simplify numeric expressions to a large extent during construction. -$p / q$ is represented by `Div(p, q)`. The result of `*` on `Div` is maintainted as a `Div`. For example, `Div(p_1, q_1) * Div(p_2, q_2)` results in `Div(p_1 * p_2, q_1 * q_2)` and so on. The effect is, in `Div(p, q)`, `p` or `q` or, if they are Mul, any of their multiplicands is not a Div. So `Mul`s must always be nested inside a `Div` and can never show up immediately wrapping it. This rule sets up an expression so that it helps the `simplify_fractions` procedure described two sections below. +$p / q$ is represented by `Div(p, q)`. The result of `*` on `Div` is maintained as a `Div`. For example, `Div(p_1, q_1) * Div(p_2, q_2)` results in `Div(p_1 * p_2, q_1 * q_2)` and so on. The effect is, in `Div(p, q)`, `p` or `q` or, if they are Mul, any of their multiplicands is not a Div. So `Mul`s must always be nested inside a `Div` and can never show up immediately wrapping it. This rule sets up an expression so that it helps the `simplify_fractions` procedure described two sections below. ### Polynomial representation diff --git a/page/rewrite.md b/page/rewrite.md index 5397fbbe..c1be3187 100644 --- a/page/rewrite.md +++ b/page/rewrite.md @@ -74,7 +74,7 @@ Notice that the expression was autosimplified before application of the rule. Matcher pattern may contain slot variables with attached predicates, written as `~x::f` where `f` is a function that takes a matched expression and returns a boolean value. Such a slot will be considered a match only if `f` returns true. -Similarly `~~x::g` is a way of attaching a predicate `g` to a segment variable. In the case of segment variables `g` gets a vector of 0 or more expressions and must return a boolean value. If the same slot or segment variable appears twice in the matcher pattern, then at most one of the occurance should have a predicate. +Similarly `~~x::g` is a way of attaching a predicate `g` to a segment variable. In the case of segment variables `g` gets a vector of 0 or more expressions and must return a boolean value. If the same slot or segment variable appears twice in the matcher pattern, then at most one of the occurrence should have a predicate. For example, @@ -133,7 +133,7 @@ acpyid = @acrule sin(~x)^2 + cos(~x)^2 => 1 acpyid(cos(x)^2 + sin(x)^2 + 2cos(x)*sin(x)) ``` -It has been some work. Fortunately rules may be [chained together](#chaining rewriters) into more sophisticated rewirters to avoid manual application of the rules. +It has been some work. Fortunately rules may be [chained together](#chaining rewriters) into more sophisticated rewriters to avoid manual application of the rules. ## Composing rewriters diff --git a/src/SymbolicUtils.jl b/src/SymbolicUtils.jl index 1fb7d777..fab2b864 100644 --- a/src/SymbolicUtils.jl +++ b/src/SymbolicUtils.jl @@ -63,7 +63,7 @@ include("substitute.jl") include("code.jl") -# ADjoints +# Adjoints include("adjoints.jl") end # module diff --git a/src/code.jl b/src/code.jl index 23ca867e..7c647ba9 100644 --- a/src/code.jl +++ b/src/code.jl @@ -448,7 +448,7 @@ You can define: # and -@inlline function create_array(::Type{<:MyArray}, T, ::Val{dims}, elems...) where dims +@inline function create_array(::Type{<:MyArray}, T, ::Val{dims}, elems...) where dims ``` which creates an array of size `dims` using the elements `elems` and eltype `T`, to allow diff --git a/src/interface.jl b/src/interface.jl index 264949cf..255ef584 100644 --- a/src/interface.jl +++ b/src/interface.jl @@ -45,8 +45,8 @@ function arguments end """ unsorted_arguments(x::T) -If x is a term satisfying `istree(x)` and your term type `T` orovides -and optimized implementation for storing the arguments, this function can +If x is a term satisfying `istree(x)` and your term type `T` provides +an optimized implementation for storing the arguments, this function can be used to retrieve the arguments when the order of arguments does not matter but the speed of the operation does. """ diff --git a/src/rule.jl b/src/rule.jl index 8f61ab52..a872222e 100644 --- a/src/rule.jl +++ b/src/rule.jl @@ -169,7 +169,7 @@ Creates a `Rule` object. A rule object is callable, and takes an expression and it if it matches the LHS pattern to the RHS pattern, returns `nothing` otherwise. The rule language is described below. -LHS can be any possibly nested function call expression where any of the arugments can +LHS can be any possibly nested function call expression where any of the arguments can optionally be a Slot (`~x`) or a Segment (`~~x`) (described below). If an expression matches LHS entirely, then it is rewritten to the pattern in the RHS diff --git a/src/types.jl b/src/types.jl index b3ba5dc0..c646ec47 100644 --- a/src/types.jl +++ b/src/types.jl @@ -871,7 +871,7 @@ end """ promote_symtype(f::FnType{X,Y}, arg_symtypes...) -The output symtype of applying variable `f` to arugments of symtype `arg_symtypes...`. +The output symtype of applying variable `f` to arguments of symtype `arg_symtypes...`. if the arguments are of the wrong type then this function will error. """ function promote_symtype(f::BasicSymbolic{<:FnType{X,Y}}, args...) where {X, Y} diff --git a/test/fuzzlib.jl b/test/fuzzlib.jl index adac553c..03ebcf0f 100644 --- a/test/fuzzlib.jl +++ b/test/fuzzlib.jl @@ -61,7 +61,7 @@ const bool_spec = let fns = vcat(1 .=> [(!), (~)], 2 .=> [(|), (&), xor], - 3 .=> [ifelse]) # cond will still stay in bool by condtruction + 3 .=> [ifelse]) # cond will still stay in bool by construction (leaves=bool_leaf_funcs, funcs=fns,