> 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. 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. > > > I think that the strategies should remain as pure python functions. > > I am also totally supportive of this idea. > > > 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. > I tihnk that we should eventually develop some more interesting way to > > generate rules. My vote is pattern matching triples (from-expr, to-expr, > > condition) because this is what I'm used to but there are lots of good > > options. I think that this should happen later as the result of lots of > > trial and error. Everything so far is very flat so it should be easy to > > convert existing code to some new system. > > Just to make sure: when you say "rule generator" you mean a function > which returns another function, which is actually a rule? > That, some sort of class system, anything that we choose to build on top of rules. I'm not yet voicing strong preferences on what I think this should be. > 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) > If so, then, maybe, sometimes it will be useful to be able to have > rules of the form (from_expr, rule_function, condition), i.e., not to > impose the necessity to specify the to_expr, but instead require a > transformation function. This will allow keeping the actual pattern > matching functionality out of rule_function, but will still make it > possible to describe certain transformations in a simple way. > Sure. There are lots of good ideas here. I'm not sure what is best. This will probably take a lot of experimentation to figure out. > > 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) I hope it will > grow to cover more of SymPy. I also hope to be able to contribute to > it soon. > Awesome. I'm unlikely to apply this outside of MatrixExpressions and Sets anytime in the near future (this is a brief interlude for me when I should be working on my thesis.) Extra minds and hands are welcome. -- 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.
