On Sun, Mar 28, 2010 at 10:08 PM, Aaron S. Meurer <asmeu...@gmail.com> wrote: > > 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.
Yes, we should finish it. > > 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. I see. Yes, we should keep improving simplify(). One has to be careful so that simplify() is sufficiently robust, which it is currently. But I can imagine once trigsimp() becomes robust, it can be called from simplify(). 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.
