On Sun, Mar 28, 2010 at 9:30 PM, Brian Granger <ellisonbg....@gmail.com> wrote: >> For what it's worth, I am +1 on adding these common functions as methods. >> It is easier than ^Asimplify(^E), and the parentheses are nicer. Frankly, >> the ability to do f(x).diff(x) is one of my favorite features of sympy. > > I am also +1. The *most annoying* aspect of sympy right now is that > only *some* things are methods and others are functions. To the new > user the choices seem completely arbitrary and it makes using/learning > sympy a pain. In my opinion, it is too late to go back now. When
What do you mean "go back"? It's never late to fix things. > something makes sense to be a method and a function is should be > >> Wasn't the point of splitting Basic so that we could put this bloating crap >> in the one class and have only the essentials in the other? In other words, >> the one level isn't so much at the "core" as the other. >> >> Here's an interesting question: Matrix.simplify() simplifies in place. >> Should Basic.simplify() do the same? > > No, I do think that Basic.simplify should just call the global. If > subclasses need to override it (containers like Matrix will probably > want to do it inplace). Possibly better would be to make > inplace=False a keyword argument of simplify. simplify(), diff(), expand(), factor() and all the other functions never do things in place. The only exception is Matrix, which is a container and it makes sense to do that inplace (possibly turning this off if the user doesn't want it). > > NOTE: I think the question of how a function like simplify is > implemented is a different question than how users call it. The > current discussion only pertains to how users call it. > > THE OTHER ISSUE: Personally, I think all sympy classes should be able > to declare a _simplify_ method that the global simplify might use to > simplify the logic. Something like what we have in the printers. > Otherwise it is very difficult to implement new sympy types that know > how to simplify themselves - an issue that I am running into in the > new quantum stuff I am doing. Also, this is the essence of object > oriented excapsulation: put all the logic pertaining to the class *in* > the class. But, as our experience with printerss has shown it is also > useful to be able to put some logic of a certain type (printing, > refine, simplify) in a location outside of Basic. In many ways, it > looks like we need both. I am +1 to _simplify_. As the zen of python says: " Special cases aren't special enough to break the rules. Although practicality beats purity. " I think it's convenient to have things like expand() both as a function and as a method. I don't know if everything should be accessible as methods, but I think that most of the things should be, in particular simplify() should be there as a method too. > > a side question: My understanding of Mathematica's simplification > algorithm is that it is based on rules. Has anyone looked into > something like this for sympy? In sympy, most of the simplifications are done by the polys I think. Is simplification an issue? Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
