> > You are going to have a ton of functions that look exactly the same: >
> if expr.is_whatever: apply rule > else: pass > > My point is that we should write that once, in the IdentityRule class, and > just change the identity in the subclass. > I think that there are many ways to avoid repeated code. Objects and inheritance are one such way but not the only way. Additionally, there is duplication by writing essentially the same identity > twice with tan -> sin/cos and sin/cos -> tan. So I think that since we have > a solve() function, we should be able to write it just once, and figure out > how to get what we want from what we have. > Valid point. > If all this is buried in function closures, we won't be able to use the > data (in this case, the identities) in any kind of intelligent way > Valid point. Debugging through many function calls is somewhat annoying. > , other than "try doing things (randomly) in different orders to see what > you get". > Ah, here you're talking about strategies I disagree with this. You can imbue strategies with other information apart from just the rule. We might associate the Tan/Sin/Cos rules in a strategy with their types so that we only apply rules appropriately. This is an efficiency concern and is handled separately. > Remember that sympy can do complex math. If we have a system of equations, > we can solve that system. If we have a set of logical statements, we can > make deductions from those statements. If some chain of rules somehow > telescopes to something far simpler, we can symbolically compute that. We > should use this fact whenever possible, which means representing things > symbolically whenever possible. > Yes. This is certainly a strength of ours and I share the belief that when we leverage this strength we usually win. My suggestion is that we build Systems that build rules using some of SymPy's awesomeness. I'm personally looking forward to using match and replace to build rules. This should be awesome. I don't think we disagree that much. You're saying "Lets build an class hierarchy around these rules" I'm saying "Lets build higher order functions around rules". These aren't exclusive. The functions I'm building<https://github.com/mrocklin/sympy/tree/rr/sympy/rr>are very base-level. We can build things on top of them. Before I said the following "We may very well want a more structured way to define a rule than a python function" And I'm still saying that. We'll probably want to describe the rules in some more structured way. This is, I think, what you're saying too. -- 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.
