I've added a new PR for branching rewrite rules. These support rules which may produce multiple results. This has been an interesting exercise in both higher order functions and lazy iterators. I wasn't able to implement it as cleanly as I'd like. If there are any functional programming gurus out there I would appreciate any tips.
https://github.com/sympy/sympy/pull/1632 On Thu, Oct 4, 2012 at 7: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.
