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 <[email protected]> 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 <[email protected]> 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. -- 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.
