On Thu, Apr 14, 2011 at 4:29 AM, Julien Rioux <julien.ri...@gmail.com>wrote:
> On Apr 13, 5:54 pm, Hector <hector1...@gmail.com> wrote: > > On Thu, Apr 14, 2011 at 2:29 AM, Aaron S. Meurer <asmeu...@gmail.com> > wrote: > > > > > > > > > > > > > On Apr 13, 2011, at 2:22 PM, Hector wrote: > > > > > On Wed, Apr 13, 2011 at 11:46 PM, Julien Rioux <julien.ri...@gmail.com > >wrote: > > > > >> On Apr 13, 11:45 am, Hector <hector1...@gmail.com> wrote: > > >> > Hello groups, > > > > >> > This is about the way limit has been defined in sympy. Currently, > Sympy > > >> > gives following result. > > > > >> > In [1]: limit(abs(x)/x,x,0) > > >> > Out[1]: 1 > > > > >> > But as we know, the right-hand and left-hand of limit at given > function > > >> is > > >> > different. > > > > >> > In [2]: limit(abs(x)/x, x, 0, dir = "+") > > >> > Out[2]: 1 > > > > >> > In [3]: limit(abs(x)/x, x, 0, dir = "-") > > >> > Out[3]: -1 > > > > >> > And hence mathematically speaking, limit doesn't exist at given > point. > > >> Sympy > > >> > assumes dir = "+" by default and hence giving the wrong answer. The > > >> similar > > >> > type of discussions has been made some times ago in Issue1000[1]. As > > >> > suggested in discussions, the default dir should be " r " for real > line > > >> > where it checks both right hand side and left hand side limit and > > >> returns > > >> > the answer iff both are equal. For this to happen, I am proposing > that > > >> we > > >> > should rename current "limit" function by "limit_eval" and define > new > > >> limit > > >> > function which checks both right hand limit and left hand limit. > > > > >> > I made the necessary changes, and the corresponding pull request is > > >> #219[2]. > > >> > If this changing definition things is fine with core developers, I > would > > >> > like to proceed further for limts of bi-variant functions. > > > > >> > -- > > >> > -Regards > > >> > Hector > > > > >> > Whenever you think you can or you can't, in either way you are > right. > > > > >> > [1] > > >>http://code.google.com/p/sympy/issues/detail?can=2&q=1000&colspec=ID%. > .. > > >> > [2]https://github.com/sympy/sympy/pull/219 > > > > >> I do appreciate when sympy's functions are based as closely as > > >> possible on the mathematical definition, so I am +1 on this general > > >> idea. However: > > > > >> - Introducing limit_eval is repetitive. Just use limit(..., dir="+") > if > > >> that is the intended behavior. > > > > > But in mathematical literature, limit always implies limit from both > > > directions( on real line) unless until specified. So as discussed in > > > Issue1000, limit (modified) will be 2x as much time consuming as limit > ( > > > with old definition) but that will give us mathematically correct > answer and > > > I believe that counts more than speed. Moreover, we can never think of > limit > > > of bi-variant functions or limit in complex plane if we go with current > > > definition of limit. > > > > > At what point in the algorithm does it use the direction of the limit? > Is > > > it from the outset, or is it after it has done some other things? If > it's > > > the second case, then we could optimize it so it doesn't take 2x as > long. > > > > > Aaron Meurer > > > > The way I understand the code, it uses the definition of limit ( with > > direction carried forward from original question) several time for one > > example so I guess it is second case. It forms the set of most rapidly > > varying subexpressions from given functions for which it need to check > limit > > x->oo |f(x)| but directions are surly not used in this case. > > As we all know, Ondrej Certik will be the best person to answer this. > > > > Meanwhile the overview of modified code is - > > > > def limit_eval ( ... ,dir = "+"/"-") : > > ## Previously defined limit function which returns the value of limit > > with specified direction. > > > > def limit ( ... , dir = "r") : > > if dir == r : > > limit_right = limit_eval( ... , dir = "+") > > limit_left = limit_eval( ... , dir = "-") > > if limit_right == limit_left : > > return limit_right > > else : > > return PoleError > > else : > > return limit_eval( ... , dir ) > > > > So most of my work is in limit.py and I did little modification in > gruntz.py > > ( indeed in order.py) to make it consistent with new definition. > > > > Again, I wouln't introduce a new function limit_eval() here. There is > already a general purpose function: gruntz(). That one will probably > need to be called twice, at least as a first implementation of > dir="r". > > Next, there are some special cases in the limit function before > resorting to gruntz(), that could easily be extended to treat dir="r". > Most of them do some manipulation before eventually checking the value > of dir, and you don't have to do these manipulations twice. > > Thanks for pointing it out. I made a new pull request[1] in which I modified the gruntz function and hence most of the manipulation that used to happen before gruntz() need not be done twice. If there is any further scope of improvement, please let me. > > > > > > > > > >> - The default for the dir argument should depend on the assumptions on > > >> x. So you would get dir="r" when x is declared Symbol("x", real=True) > > >> but dir=(complex plane, I don't know the key, c?) when x is declared > > >> Symbol("x", complex=True). > > > > >> Regards, > > >> Julien > > > > > This seems reasonable to me and thanks for pointing it out. I don't > think > > > currently there is any method available to compute limit when variable > is > > > complex. I will fix this while writing (if people permit) limit for > complex > > > variable. > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "sympy" group. > > >> To post to this group, send email to sympy@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. > > > > > -- > > > -Regards > > > Hector > > > > > Whenever you think you can or you can't, in either way you are right. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "sympy" group. > > > To post to this group, send email to sympy@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. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "sympy" group. > > > To post to this group, send email to sympy@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. > > > > -- > > -Regards > > Hector > > > > Whenever you think you can or you can't, in either way you are right. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@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. > > -- -Regards Hector Whenever you think you can or you can't, in either way you are right. [1] https://github.com/sympy/sympy/pull/230 -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@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.
