I have looked through all the commits. It's so very nice! I like the small and clean functions, which combine so nicely, and which look very flexible and extensible at the same time. Getting back to the discussion about how easy will using an FP-based rewriting system be vs. an OOP-based one, I'd like to note that what you have done so far is remarkably clear.
On Sat, Oct 6, 2012 at 4:58 PM, Matthew Rocklin <[email protected]> wrote: > > My experience from building this is that there are some rules like unpack, > flatten, and rmid (remove identities) which I think should remain as they > are. There are some rules that I had to make for MatMul and MatAdd which > could probably be made easier through a more structured rule creation system > like what Aaron is discussing. xxinv is a good example of this. The rules for MatMul and MatAdd are already rather comprehensible as they are, but yes, xxinv is better structured. > The strategies I really like exactly as they are. (you should check out the > definition of canon - the canonicalization strategy.) Oh yeah, canon() is absolutely beautiful. I expect that the majority of strategies can be constructed in a similarly clear way, and that's what I like about your approach. > 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 :-) ) > 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? 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? 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. > 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. > This was also a task that was supposed to be very difficult because it meant > rewriting a very dense part of SymPy's core for MatrixExprs. This was done > with, I believe, a minimal amount of effort once the strategies were in > place. The logic for simplification is now also very testable. Every little > piece of logic is separately available for unit testing. I feel very enthusiastic about your solution. It is astonishingly clean and addresses serious issues with apparent ease. I hope it will grow to cover more of SymPy. I also hope to be able to contribute to it soon. Thanks for the cool work :-) 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.
