On Mar 28, 2010, at 11:02 PM, Ondrej Certik wrote: > 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 > Simplification is one of the weak points of sympy. Polynomial based simplification is pretty strong, especially with the new polys. But, for example, our trig simplification is very poor. The fu, et. al. paper that has been mentioned here a few times uses rules. I think we should finish up Luke's work on that one.
Also, maybe he means things like "does it contain logs in this certain form, then try calling logcombine(); does it contain trig functions, then try calling trigsimp(), does it contain nested squareroots, then try calling sqrtdenest(), etc.". We have all these functions, and some of them work quite well, but simplify() by itself is quite stupid (it doesn't even call any of these three that I just mentioned). This is because calling everything would be a waste of time, and it could actually make things less simple in many cases, but it should be smarter about this IMHO, because simplify() is the first thing people are going to try on a complex expression. Aaron Meurer -- 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.
