On Sun, Oct 7, 2012 at 12:58 AM, Matthew Rocklin <[email protected]> wrote: >> The idea X Inverse(X) => Identity(X.rows) is substantially simpler than >> the >> >> > code that was necessary to encode this rule though. This is going to be >> > a >> > common sort of rule so this is the sort of thing we should generalize >> > somehow. >> >> How about a predicate cancellable()? Thus, x (op) y will be >> transformed into identity if cancellable(x, y). The generalised >> function may then work as follows: >> >> def mat_cancellable(X, Y): >> return Y == Inverse(X) >> >> cancel(composite_expression, mat_cancellable, I) >> >> where composite_expression is an instance of Mul, Add, MatMul, MatAdd, >> etc. If it is possible to extract the identity from this operations, >> then the third argument will be unnecessary. > > I wonder if there is a way to generalize this thinking so that it can be > applied to more cases that aren't just cancellation.
I'm not sure as to what exactly you refer to. I actually think that in all cases where a pair x (op) y is transformed into identity one has a monoid (M, (op)) with identity e, so that x (op) y = e. That is, I actually think that all the cases where such reasoning is applicable are cancellations in a monoid. >> > Ah, sorry, I was using pure in the sense of "lets just use this >> > function, >> > not a class that represents this function". I wasn't using "pure" in the >> > side-effect-free sense. I do however think that this system should be >> > (mostly) side-effect free (mostly for caching, profiling, debug, >> > etc....) >> > That's somewhat standard in SymPy though. >> >> Yes, and that's an advantage. Although functions with side-effects >> should also be handled nicely, because, from what I know, there >> actually are some mutable objects in SymPy. > > Rules as they're currently written only work on objects that inherit from > Basic. All Basics are immutable. Rules assume immutability. The mutable > types in SymPy (notably Matrix) do not inherit from Basic. Ah, I see; I thought Matrix inherited from Basic as well. >> >> Further, when you say "pattern matching triples", do you mean >> >> representing rules as triples and having the application function >> >> which checks whether its argument matches from-expr and satisfies the >> >> condition, and then returns to-expr? >> > >> > Yes. I would like to write xxinv as >> > X = Wild() >> > xxinv = rule(X*Inverse(X), Identity(X.rows), True) >> > or >> > sym_transpose = rule(Transpose(X), X, X.is_symmetric) >> >> Looks very nice. Shouldn't be that hard to implement either, I think. > > This depends on pattern matching, a challenging problem. SymPy might have > tools to handle it though. I'm not sure how well Wild works, but, apparently, we can use it to do some pattern matching. I've never used Wild, though; I just assumed that it's sufficiently powerful. If this is indeed the case, then the format of rules you suggest should be straightforward to implement. 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.
