> 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. > 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. > >> 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<http://en.wikipedia.org/wiki/Pattern_matching>, a challenging problem. SymPy might have tools to handle it though. > Oh. I'm slightly upset to find out that matrix expressions don't fit > nicely within Expr; I thought Expr should represent a general > expression. I believe I just have to read more code; sorry for > off-topic :-) > See note above. I think it is both good and natural that Expr is effectively ScalarExpr. This really isn't a problem. Basic is really the clean core class that we should care about. -- 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.
