limit of fraction with oscillating term in the numerator calculated incorrectly

[Ilya Schurov]

http://code.google.com/p/sympy/issues/detail?id=3500

In [2]: limit((n+cos(n))/n,n,oo)
Out[2]: nan

Should be 1, due to cos(n) is limited.

It seems that there are problems with calculating limits of oscillating functions, e.g.

In [3]: limit(cos(n),n,oo)
Out[3]: cos(∞)

Which should return nan instead or show that there is no limit in other way.

[Ondřej Čertík]

Hi Ilya,

You are right, the oscillating functions don't work as they should.
Thanks for reporting it.

Ondrej

[Ilya Schurov]

Hi, Ondrej,

Are there any known reasons why it works like this? Any ideas how to fix it?

--
I.V.

[Aaron Meurer]

Ondrej might be able to answer better, as he implemented this, but the work-horse of the limit() function is the Gruntz algorithm, from Dominik Gruntz's PhD thesis (http://www.cybertester.com/data/gruntz.pdf). limit() is gruntz() plus some heuristics.

My guess is that either the Gruntz algorithm is not well suited to oscilating functions, or else the relevant parts are not implemented.

Aaron Meurer

--
You received this message because you are subscribed to the Google Groups "sympy" group.

To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/Cb26ChOqDqQJ.

To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

[someone]

> My guess is that either the Gruntz algorithm is not well suited to
> oscilating functions, or else the relevant parts are not implemented.

As far as I understand the algorithm, it is not
able to handle oscillating stuff due to the
properties of these function fields.


-- Raoul

[Tom Bachmann]

Hi,

Aaron is right. The Gruntz algorithm does not support oscillatory
functions like cos(x), and last time I thought about it there seemed no
easy way to extend it. As such all oscillatory limits are done using the
heuristics, which in my experience tend to be somewhat unpredictable ...

The basic gruntz algorithm works with all functions formed by algebraic
combinations of exponentials and logarithms of *real* numbers, so in
particular rational functions, real powers, etc. It also works with
functions which, about points of interest, admit (asymptotic) expansions
of this form. Thus it can compute limits like cos(1/x), x->oo [b/c 1/x
-> 0, and cos has a power series expansion about 0], or arctan(x), x ->
oo [b/c arctan has an asymptotic expansion around oo]. It cannot
directly handle limits of gamma functions (with argument tending to
infinity), but you can rewrite gamma(x) = exp(loggamma(x)), and
loggama(x) *does* have an asymptotic series about oo [and that is what
the algorithm does].

In general a function is called tractable at x_0 in [-oo, oo] if it
admits a series expansion of the required form, and the algorithm can
only work with tractable functions. But cos isn't tractable at infinity.

Now of course we *know* the behaviour of cos at infinity. If we could
find a way to express the fact that cos(x) is bounded oscillatory as
x->oo, gruntz could probably be adapted to compute limits like this. The
difficulty is in coming up with a sufficiently general descriptions of
things like "bounded oscillatory", which has the following properties:

- gruntz can be adapted to work with these kinds of objects
- the objects are mathematically sound
- we can get meaningful answers in interesting cases

Unfortunately, these properties tend to collide. You are very much
invited to come up with a solution :-).

Best,
Tom

On 18.11.2012 21:43, Aaron Meurer wrote:
> Ondrej might be able to answer better, as he implemented this, but the
> work-horse of the limit() function is the Gruntz algorithm, from Dominik
> Gruntz's PhD thesis (http://www.cybertester.com/data/gruntz.pdf).
> limit() is gruntz() plus some heuristics.
>
> My guess is that either the Gruntz algorithm is not well suited to
> oscilating functions, or else the relevant parts are not implemented.
>
> Aaron Meurer
>
>
> On Sun, Nov 18, 2012 at 7:53 AM, Ilya Schurov <ilya.s...@gmail.com
> <mailto:ilya.s...@gmail.com>> wrote:
>
> Hi, Ondrej,
>
> Are there any known reasons why it works like this? Any ideas how to
> fix it?
>
> --
> I.V.
>
>
> On Wednesday, November 14, 2012 12:42:33 AM UTC+4, Ondřej Čertík wrote:
>
> Hi Ilya,
>
> On Sun, Nov 11, 2012 at 12:43 PM, Ilya Schurov
> <ilya.s...@gmail.com> wrote:

> > http://code.google.com/p/__sympy/issues/detail?id=3500

> <http://code.google.com/p/sympy/issues/detail?id=3500>
> >
> > In [2]: limit((n+cos(n))/n,n,oo)
> > Out[2]: nan
> >
> > Should be 1, due to cos(n) is limited.
> >
> > It seems that there are problems with calculating limits of
> oscillating
> > functions, e.g.
> >
> > In [3]: limit(cos(n),n,oo)
> > Out[3]: cos(∞)
> >
> > Which should return nan instead or show that there is no
> limit in other way.
>
> You are right, the oscillating functions don't work as they should.
> Thanks for reporting it.
>
> Ondrej
>
> --
> You received this message because you are subscribed to the Google
> Groups "sympy" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sympy/-/Cb26ChOqDqQJ.
>
> To post to this group, send email to sy...@googlegroups.com

> <mailto:sy...@googlegroups.com>.

> To unsubscribe from this group, send email to
> sympy+un...@googlegroups.com

> <mailto:sympy%2Bunsu...@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.

[Aaron Meurer]

On Sun, Nov 18, 2012 at 3:00 PM, Tom Bachmann <e_m...@web.de> wrote:

Hi,

Aaron is right. The Gruntz algorithm does not support oscillatory functions like cos(x), and last time I thought about it there seemed no easy way to extend it. As such all oscillatory limits are done using the heuristics, which in my experience tend to be somewhat unpredictable ...

The basic gruntz algorithm works with all functions formed by algebraic combinations of exponentials and logarithms of *real* numbers, so in particular rational functions, real powers, etc. It also works with functions which, about points of interest, admit (asymptotic) expansions of this form. Thus it can compute limits like cos(1/x), x->oo [b/c 1/x -> 0, and cos has a power series expansion about 0], or arctan(x), x -> oo [b/c arctan has an asymptotic expansion around oo]. It cannot directly handle limits of gamma functions (with argument tending to infinity), but you can rewrite gamma(x) = exp(loggamma(x)), and loggama(x) *does* have an asymptotic series about oo [and that is what the algorithm does].

Maybe we can try to find some similar combination of functions for cos, which we can work with. Maybe somehow sinc (sin(x)/x) would be more useful, as it goes to zero at infinity.  

I'm just shooting in the dark, though.  I haven't yet read Gruntz's thesis.

 

In general a function is called tractable at x_0 in [-oo, oo] if it admits a series expansion of the required form, and the algorithm can only work with tractable functions. But cos isn't tractable at infinity.

Now of course we *know* the behaviour of cos at infinity. If we could find a way to express the fact that cos(x) is bounded oscillatory as x->oo, gruntz could probably be adapted to compute limits like this. The difficulty is in coming up with a sufficiently general descriptions of things like "bounded oscillatory", which has the following properties:

- gruntz can be adapted to work with these kinds of objects
- the objects are mathematically sound
- we can get meaningful answers in interesting cases

So some kind of useful extension of the squeeze theorem? 

Aaron Meurer

 

    sympy+unsubscribe@googlegroups.com

    <mailto:sympy%2Bunsubscribe@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 sy...@googlegroups.com.
To unsubscribe from this group, send email to

sympy+unsubscribe@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 sy...@googlegroups.com.

To unsubscribe from this group, send email to sympy+unsubscribe@googlegroups.com.

[someone]

Hi,

> Aaron is right. The Gruntz algorithm does not support oscillatory
> functions like cos(x), and last time I thought about it there seemed
> no easy way to extend it.

> The difficulty is in coming up with a sufficiently general
> descriptions of things like "bounded oscillatory", which has the
> following properties:
>
> - gruntz can be adapted to work with these kinds of objects
> - the objects are mathematically sound
> - we can get meaningful answers in interesting cases
>
> Unfortunately, these properties tend to collide. You are very much
> invited to come up with a solution :-).

There is some work done on this topic, see for example the short
paper "On the computation of limsups" by Joris van der Hoeven.

He did a lot of work on what he calls "automatic asymptotics":

http://www.texmacs.org/joris/phd/phd-abs.html

This is based on so called transseries and the algorithms in
his PhD *might* be ready for an actual implementation. It's for
sure a worthwhile lecture but I did not read it, it's pretty
complicated math for my mind.