I should also point out that I'm not against a Rule object or whatever. We may very well want a more structured way to define a rule than a python function. This could be (FromExpr, ToExpr, Condition) triples with pattern matching and replace. It could be a class hierarchy of Rule objects. It could be lots of things.
I plan to build a tight functional core and a single loose implementation for MatrixExpressions. Hopefully this will generate some issues and ideas that will guide our decisions for how to create a more specific system in the future. On Fri, Oct 5, 2012 at 10:58 AM, Matthew Rocklin <[email protected]> wrote: > On Fri, Oct 5, 2012 at 9:59 AM, Aaron Meurer <[email protected]> wrote: > >> Well probably all transformation/simplification rules can be formulated >> as identities. One possible extension is an identity that only holds for >> certain assumptions, like log(x*y) -> log(x) + log(y). But to really do >> those right, I think we need to flesh out the assumptions system. >> > > A good assumptions system would certainly allow a number of very rich > rules. Rewrite rule languages are often prolog-y. > > >> By the way, the set module might also be an interesting place to play >> around with this, especially given some of the nontrivial stuff like >> http://code.google.com/p/sympy/issues/detail?id=3376 that can happen. >> > > The set module already has a rudimentary rule-based simplification built > into it with the _union and _intersection methods. The transformations are > separate from how they are applied. This was introduced in > https://github.com/sympy/sympy/pull/1133 > https://github.com/sympy/sympy/pull/1164 > > It should be very easy to lift these to some more general system. > -- 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.
