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.
But if you think about it, just about any method and function in SymPy could be sold as a rule, because they take expressions as input and return an expression as output (you may need to generalize "expression" to include lists, tuples, sets, and dictionaries of expressions). So, for example, subs is a "rule" that transforms an expression into another expression that is the input expression evaluated at a point. http://code.google.com/p/sympy/issues/detail?id=2714 and http://code.google.com/p/sympy/issues/detail?id=1932 are interesting classes to think about. In both cases, we want simple rules that transform the objects. And in both cases, the rules apply to general objects. In 2714, most of the rules apply to Sum and Integral, but they do not share a common base class. A general rule might be "object a is linear in argument n", and then all the logic for splitting or combining sums, or for pulling out or pushing in constants could be in one place. Or, more generally, a homomorphism rule, which tells how one operation becomes another (like the log example I gave above). 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. Aaron Meurer On Oct 5, 2012, at 7:27 AM, Matthew Rocklin <[email protected]> wrote: Question: What are the standard types of simplifications that we do? The example above I would generalize as "Remove identities" We might also have other generalizable simplifications. Any thoughts? On Fri, Oct 5, 2012 at 6:26 AM, Sergiu Ivanov <[email protected]>wrote: > Hello, > > On Fri, Oct 5, 2012 at 5:02 AM, Matthew Rocklin <[email protected]> > wrote: > > > >> > 2. It is a bit more sophisticated/clever. Requires you to think about > >> > higher > >> > order functions > >> > >> I think if you use a good class structure then it won't be. To create > >> a new rule, one just has to create a subclass of something (maybe a > >> similar rule, maybe a base Rule class), that just defines the key > >> components of the rule (i.e., those parts that make that rule > >> different from other rules). All the if, else, map, etc. stuff should > >> be abstracted in base classes. > > > > This is a personal preference but I strongly prefer higher order > functions > > to inheritance. My prototype is unlikely to be OO. I think that objects > are > > overkill for this task. > > I would like to vote for higher order functions as well. I agree that > higher-order functions impose a little bit more thinking burden on a > contributor with little or no background in functional programming; > however, the strategies and rules as presented by Matthew are actually > quite easy to grasp without a strenuous thinking process. > > On the other hand, since writing strategies is more of a CS task, > while the rules themselves contain the actual mathematical > transformations, I think using the functional approach will be even > less effort-demanding for contributors who are well-versed in maths > but not that strong in CS. > > And yet on the other hand, once one gets beyond simple examples, I > believe the contrast between the complexity of class structures > vs. the complexity of combining high-order functions diminishes. > > >> I'm glad that someone is finally taking initiative on this. I think > >> that MatrixExpressions are both expressive enough but small enough to > >> make a good testing ground for these ideas. > > > > I agree. I'm quite fond of that little module. > > I'm looking forward to it! I hope to have slightly more time in a > couple days, so I'll be able to contribute more the discussion and > coding. > > Sergiu > > -- > 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. -- 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.
