what should limit(x - oo, x, oo) give?

[smichr]

I would have expected NaN to be returned but I get:

h[1] >>> limit(x-oo,x,oo)
oo
h[2] >>> limit(oo-x,x,oo)
-oo

[Tom Bachmann]

Evidently neither gruntz nor limit play along particularly well with
infinities. Clearly this should be nan. I'll try to look into the
gruntz issue today.

[Tom Bachmann]

Ok so the problem is in gruntz, in a sense: when you do something like
gruntz(x-oo, x, oo) then the leadterm expansion is w - oo, and gruntz
assumes that this tends to oo, simply because gruntz does not deal
with unbounded numbers at all.

The proper way to fix this is to make gruntz aware of "unbounded
numbers", this extending mrv_leadterm and changing a few things
slightly in gruntz.py. It should be easy. Downside is that 1) it
involves parts of the code that are touched in my gruntz_eval branch,
so I'd rather not fix this before the branch is in, and 2) that really
this is only going to work in trivial cases like x+oo because a)
behaviour of oo and the like is not really specified in complicated
expressions and b) series expansions at any rate are not ware of this.

An alternative (recognising that we are only going to be able to
handle trivial cases) would be to change limit(), e.g. like this:

diff --git a/sympy/series/limits.py b/sympy/series/limits.py
index 12a27d7..ae1c3ec 100644
--- a/sympy/series/limits.py
+++ b/sympy/series/limits.py
@@ -37,6 +37,14 @@ def limit(e, z, z0, dir="+"):
z = sympify(z)
z0 = sympify(z0)

+ if e.is_Mul or e.is_Add:
+ a, b = e.as_independent(z)
+ if b != e:
+ return e.func(a, limit(b, z, z0, dir))
+
+ if e.has(oo, -oo):
+ raise NotImplementedError('Could not separate infinites')
+
if e == z:
return z0


But then there is a second problem: this exception is actually raised
in some tests (where slightly ludicrous limits like (1+x)**oo are
computed). Remove the check would fix this, but then we might
sometimes compute the wrong answer.


I don't really think it's worth the hassle fixing this as long as we
can only do trivial cases anyway.

[Ronan Lamy]

Le vendredi 29 avril 2011 à 09:50 -0700, Tom Bachmann a écrit :
<snip>

> I don't really think it's worth the hassle fixing this as long as we
> can only do trivial cases anyway.
>

I think limit() needs to get smarter, not gruntz(). It should be able to
perform appropriate simplifications based on the information that the
variable goes to the limit point.

> On 29 Apr., 09:55, Tom Bachmann <ness...@googlemail.com> wrote:
> > Evidently neither gruntz nor limit play along particularly well with
> > infinities. Clearly this should be nan. I'll try to look into the
> > gruntz issue today.
> >
> > On 29 Apr., 09:25, smichr <smi...@gmail.com> wrote:
> >
> > > I would have expected NaN to be returned but I get:
> >
> > > h[1] >>> limit(x-oo,x,oo)
> > > oo
> > > h[2] >>> limit(oo-x,x,oo)
> > > -oo

I would argue that the correct results are limit(x - oo, x, oo) == -oo
and limit(oo - x, x, oo) == oo.

The expression whose limit is taken belongs to the extended real line,
so we need to consider the topology of the extended real line. Unless
otherwise specified, limits are always evaluated for values of the
variable close to, but different from, the "destination". In this case,
this means arbitrarily large, but finite, reals. For any real x, x - oo
= -oo, so the function Lambda(x, x - oo) is constant over the reals, but
discontinuous, undefined actually, at x = +oo. However, the latter
doesn't matter for the limit, and the result is the constant value, -oo.
All this is completely parallel to limit(abs(x)/x, x, 0, '+'), for
instance.

[Aaron S. Meurer]

That's a good point. Putting oo in an expression assumes the extended real line.

Another idea is that if there were a way to take multiple limits at once, we could just replace all instances of oo with a second limit tending toward oo.

Aaron Meurer

[Julien Rioux]

On Apr 29, 2:17 pm, Ronan Lamy <ronan.l...@gmail.com> wrote:
> I would argue that the correct results are limit(x - oo, x, oo) == -oo
> and limit(oo - x, x, oo) == oo.
>
> The expression whose limit is taken belongs to the extended real line,
> so we need to consider the topology of the extended real line. Unless
> otherwise specified, limits are always evaluated for values of the
> variable close to, but different from, the "destination". In this case,
> this means arbitrarily large, but finite, reals. For any real x, x - oo
> = -oo, so the function Lambda(x, x - oo) is constant over the reals, but
> discontinuous, undefined actually, at x = +oo. However, the latter
> doesn't matter for the limit, and the result is the constant value, -oo.
> All this is completely parallel to limit(abs(x)/x, x, 0, '+'), for
> instance.

Take f(x,y)=x-y. By your account lim(lim(f(x,y),y,oo),x,oo) == -oo but
lim(lim(f(x,y),x,oo),y,oo) == oo. This can't be right.

--
Julien

[Ronan Lamy]

Why can't it be right? Limits that don't commute at a singular point are
a common occurrence. For instance:
lim(lim(exp(-b/a), b, 0+), a, 0+) == 1
lim(lim(exp(-b/a), a, 0+), b, 0+) == 0

Intuitively, the inner variable goes to infinity first, i.e. much faster
than the outer one.

[Tom Bachmann]

On 29 Apr., 19:17, Ronan Lamy <ronan.l...@gmail.com> wrote:
> Le vendredi 29 avril 2011 à 09:50 -0700, Tom Bachmann a écrit :
> <snip>> I don't really think it's worth the hassle fixing this as long as we
> > can only do trivial cases anyway.
>
> I think limit() needs to get smarter, not gruntz(). It should be able to
> perform appropriate simplifications based on the information that the
> variable goes to the limit point.
>
> > On 29 Apr., 09:55, Tom Bachmann <ness...@googlemail.com> wrote:
> > > Evidently neither gruntz nor limit play along particularly well with
> > > infinities. Clearly this should be nan. I'll try to look into the
> > > gruntz issue today.
>
> > > On 29 Apr., 09:25, smichr <smi...@gmail.com> wrote:
>
> > > > I would have expected NaN to be returned but I get:
>
> > > >     h[1] >>> limit(x-oo,x,oo)
> > > >     oo
> > > >     h[2] >>> limit(oo-x,x,oo)
> > > >     -oo
>
> I would argue that the correct results are limit(x - oo, x, oo) == -oo
> and limit(oo - x, x, oo) == oo.

That makes a lot of sense, but I would argue that calculating limits
in this extended system is not going to be trivial.

Wait. The following one-line patch seems to do exactly what it should
do:

diff --git a/sympy/series/gruntz.py b/sympy/series/gruntz.py
index a175b45..4dd8455 100644
--- a/sympy/series/gruntz.py
+++ b/sympy/series/gruntz.py
@@ -322,7 +322,7 @@ def limitinf(e, x):
# We make sure that x.is_positive is True so we
# get all the correct mathematical bechavior from the
expression.
# We need a fresh variable.
- p = Dummy('p', positive=True)
+ p = Dummy('p', positive=True, bounded=True)
e = e.subs(x, p)
x = p
c0, e0 = mrv_leadterm(e, x)


So my initial analysis was completely from the wrong perspective.
Sorry about that.

Does anyone see a problem with this code? Seems almost too easy.

[Julien Rioux]

Intuitively?! Oh, I see how I must have been misleading. I suppose I
should have used a different syntax than what I used. But
mathematically what is lim_{x,y->oo} x-y ? My impression is that if
the order of the limit matters I would expect "undefined" as an
answer. My intuition says that there isn't one variable going to
infinity faster. If you assume one does, then you assume a particular
answer.

Also, f(x,y)=x-y isn't singular.

--
Julien

[Tom Bachmann]

> Intuitively?! Oh, I see how I must have been misleading. I suppose I
> should have used a different syntax than what I used. But
> mathematically what is lim_{x,y->oo} x-y ? My impression is that if
> the order of the limit matters I would expect "undefined" as an
> answer. My intuition says that there isn't one variable going to
> infinity faster. If you assume one does, then you assume a particular
> answer.

The following are three different mathematical concepts:

lim(lim(f(x,y), x, oo), y, oo)
lim(lim(f(x,y), y, oo), x, oo)
lim_{x, y \to oo} f(x,y) <-- sympy does not have an expression for
this, and it wouldn't be implemented anyway

As you have just discovered, in general these need not be the same
(and in fact you can even cook up examples where all limits involved
are finite).

[Julien Rioux]

Yes, I now think it's right.
x-y as x,y go to oo is undefined, but
x-oo as x goes to oo is -oo.

Having oo by itself in an expression is a weird concept, though.

Julien

[Tom Bachmann]

I have created an issue (2326) for this.

I think I can fix it, but this needs some debugging gruntz and I had
rather only make it work with the new implementation, i.e. I'd like to
wait until gruntz_eval is in.