On Fri, Oct 5, 2012 at 4:59 PM, Aaron Meurer <[email protected]> wrote: > > 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.
Yes, and I think that's the reason why (people say that) Mathematica is built on top of a rule rewriting system. > 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). Talking about homomorphisms is a very good point. If we restrict the left-hand side and the right-hand side of the rule to be somehow "similar", we will have a less general notion of a rule, which will be much easier to handle, I think. 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.
