On Thu, Apr 14, 2011 at 2:29 AM, Aaron S. Meurer <[email protected]> wrote:
> > On Apr 13, 2011, at 2:22 PM, Hector wrote: > > > > On Wed, Apr 13, 2011 at 11:46 PM, Julien Rioux <[email protected]>wrote: > >> On Apr 13, 11:45 am, Hector <[email protected]> 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. > > >> - 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 [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. >> >> > > > -- > -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 [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. > > > -- > 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. > -- -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 [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.
