On Oct 6, 2012, at 11:40 AM, Sergiu Ivanov <[email protected]> wrote:
> On Sat, Oct 6, 2012 at 6:57 PM, Matthew Rocklin <[email protected]> wrote: >> >>> The rules for MatMul and MatAdd are already rather comprehensible as >>> they are, but yes, xxinv is better structured. >> >> >> They're certainly no more complicated than the code that was there before. > > Absolutely. > >> 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 think that there should be some rules that are pure python functions >>>> (i.e. >>>> unpack, flatten). >>> >>> If we do abide by the overall immutability of the core, we may >>> probably be able to minimise the number of rules which are _not_ pure >>> functions. (When I say "pure" I mean with no side-effects; I hope we >>> are using the same terminology :-) ) >> >> >> 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. > >>> 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. > >>>> Using these rules I was able to completely separate the dependence of >>>> MatrixExprs from Expr; a task that has been bothering me for a long >>>> time. >>> >>> I don't really know the reason why this dependency was bad, but the >>> way you used strategies to split the two is impressively clean. >> >> >> A few reasons: >> 1. People would do X.expand() and this would fail (expand is a method on >> Expr that was not implemented for MatrixExprs >> 2. MatAdd would use Add.flatten which would inject 1s and 0s into the args >> which had to be cleaned up. >> 3. Lots of other things like (2) > > 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 :-) Yes, it's a big issue. We need the ability for objects to define for themselves how they should be processed under Add and Mul, but it requires some kind of dispatch system. Even now, this still won't work if someone tries to use MatrixExprs with some function that calls Mul or Add on the args at some point, because that will bypass the rules and still call Mul.flatten or Add.flatten. Aaron Meurer > > 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.
