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.
>
>
>
>
> >> - 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.
