In general I am very much in favor of having more sophisticated
expression transformation capabilities in SymPy.  For something like
rewrite rules I would love it if we can study what Mathematica does.
Wolfram got that part right.

On Thu, Oct 4, 2012 at 5:17 PM, Matthew Rocklin <[email protected]> wrote:
> Hi Everyone,
>
> I'm planning to add a simplification system for sympy.matrices.expressions
> that is built on rewrite rules. I hope that this will be a nice test case
> for the feasibility of rewrite rules in the rest of SymPy. I would like to
> get feedback on design before I start work.
>
> First, rewrite rules are a way to transform an expression. This way tries to
> separate what happens from how it happens. We create rules like the
> following:
>
> def remove_ones(a_mul):
>     """ Remove multiplicative identities from a Mul """
>     return Mul(*[arg for arg in a_mul.args if arg != 1])
>
> These rules describe transformations that we might want to apply onto a node
> in our sympy expression. A rule is a function
>
> Expr -> Expr
>
> We combine and arrange rules with strategies. Here are two strategies
>
> def conditional(condition, rule):
>     """ Only apply rule if condition is true """
>     def new_rule(expr):
>         if condition(expr): return rule(expr)
>         else              : return expr
>     return new_rule
>
> def traverse_ast(rule):
>     """ Apply a rule down a syntax tree traversing top-down """
>     def new_rule(expr):
>         if expr.is_Atom: return rule(expr)
>         else:            return rule(expr.__class__(map(new_rule,
> expr.args)))
>     return new_rule
>
> A strategy is generally a function
>
> [Rules] Other-stuff -> Rule
>
> We might then create a rule to remove ones from all muls down a syntax tree
> as follows
>
> remove_all_ones = traverse_ast(conditional(lambda expr: expr.is_Mul,
> remove_ones))
>
> These strategies and rules are generally built up in interesting ways.
>
> What's nice about this is the following
> 1. The strategies are reusable
> 2. The rules are reusable
> 3. The rules supply very clear intent - they are easy to reason about
> 4. Efficiency is separate from logic.
>
> What's bad about this is the following
> 1. It's probably slower than what we have now
> 2. It is a bit more sophisticated/clever. Requires you to think about higher
> order functions
>
> Again, my plan is to implement this for MatrixExpressions as a test case.
> I'm posting it here now in case people have suggestions/warnings/pointers.
>
> Best,
> -Matt
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
[email protected] and [email protected]

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to