On Fri, Oct 5, 2012 at 4:42 PM, Aaron Meurer <[email protected]> wrote: > On Oct 4, 2012, at 9:02 PM, Matthew Rocklin <[email protected]> wrote: > >> I think if you use a good class structure then it won't be. To create >> a new rule, one just has to create a subclass of something (maybe a >> similar rule, maybe a base Rule class), that just defines the key >> components of the rule (i.e., those parts that make that rule >> different from other rules). All the if, else, map, etc. stuff should >> be abstracted in base classes. > > > This is a personal preference but I strongly prefer higher order functions > to inheritance. My prototype is unlikely to be OO. I think that objects are > overkill for this task. > > > I have to disagree, and believe me, I'm the last person to prefer an OO > style over an imperative one when imperative would do just fine (this is one > of the reasons that I hate Java). But in this case, I think it will remove a > lot of code duplication. You run into problems with a functional interface > in Python real fast because there are no attributes, and it's impossible to > inspect the code of the function. So you'll end up creating functions that > return dictionaries of the data you want. When that happens, you are better > off just using a class, which is a much cleaner way to have a namespace (and > you also get inheritance for free!).
I am not sure I we are talking about the same things; when I say "functional programming" I refer to programming which focuses on functions and, in particular, on higher-order functions like map, reduce, etc. and on combinations thereof. Thus, I see absolutely no problem introducing objects and classes into this _functional_ model whenever necessary. Thus there is never need to create functions which return ugly dictionaries instead of objects. > How would my tan = sin/cos example look in your proposed functional model? I must admit I'm slightly fuzzy about the semantics of IdentityRule class (and hence, that of TanRule). I will try to address your more general statement that precedes the example, though. > I think if you use a good class structure then it won't be. To > create a new rule, one just has to create a subclass of something > (maybe a similar rule, maybe a base Rule class), that just defines > the key components of the rule (i.e., those parts that make that > rule different from other rules). All the if, else, map, etc. stuff > should be abstracted in base classes. In the functional approach Matthew is proposing, to create a new rule, one just has to write a new function. I think I've just now got a better understanding of your example; I'll try to explain what that would look like with a functional approach. When the user wants to create an identity rule, they basically want to define the identity rule (1) and then have it applied as an identity rule (2). In your example, (1) is described by the constructor of TanRule, while (2) is contained in IdentityRule. With a functional approach, I would imagine having a function identity_application(), which would take the function identity_rule() describing the identity rule itself. Then I would build the composite function like application = lambda expression: identity_application(identity_rule, expression) The function application() can now be used just like TanRule. I am not sure this is the same thing as what Matthew has in mind, but, hopefully, I'm not too far away. 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.
