I think that going down this route leads us to SymPy's current (and quite capable) pattern matcher.
This unification system is completely independent from mathematical logic. I've intentionally used namedtuples to try to enforce this separation. Of course, one could build something *on top* of the unification system. For example we could try to unify, if we fail then try each of our simplification or expansion routines in some order hoping to come across a match. There are lots of more sophisticated options. I think that unification should remain an atomic building block though. On Tue, Oct 30, 2012 at 5:46 PM, Chris Smith <[email protected]> wrote: > If you want to match a + b to 2*x you just have to partition the 2. If > objects had an _eval_partition they could give you back their > partitions...just a thought. May be totally unworkable in practice. > Alternatively, you could gradually, for a failing pattern, allow > symbol degeneracy...so a + b would become a + a = 2*a if the a + b > didn't match or a + b*c would become a + a*c or a + b*b, etc... > > -- > 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. > > -- 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.
